Hi, Robert Osfield wrote: > Hi J.P, > > If its hard to make a clean non recusive lock under Windows I'm I have code that depends on the non-recursive behaviour, so I will try out the pthreads_win32 implementation and see how it goes. The old OSG code also works for me, I will have to dig in the archives to see why it was replaced and will then try to see if the pthreads_win32 does any better.
> tempted to say make OpenThreads::Mutex support recursive calls on all > platfroms, so simulate this under pthreads etc. We already have a This is one way to get to consistency, but ... > ReentrantMutex in OpenThreads, the but I'd add to this is it does add > complexity to the OpenThreads, and at a time when I really don't want > to be changing any low down in the OSG as we are about to make 2.0. I also think we should hold off low level changes to Linux code now. Having Mutex and ReentrantMutex behave the same would make one of them redundant though. > > Since most of the threading works starts off under linux and then > migrates to Windows we can say in general that out lock() don't > usually need to be recursive as I'd have deadlocks under Linux in > these instances - when these cases do exist the OSG already uses > ReentrantMutex. If we had threading code coming from Windows to > other platforms this would be a greater issue. Agree fully, don't fix the Linux code if it ain't broken. jp > > Robert. > > Robert. > > On 6/1/07, J.P. Delport <[EMAIL PROTECTED]> wrote: >> Hi all, >> >> Paul, your implementation is certainly not wrong, it just differs from >> the Linux behaviour. >> >> I have read up on the issue last night and, surprise, I was not the >> first person to stumble upon this inconsistency. >> >> What follows is what I've found. >> >> On Windows, both win32 mutexes and critical sections are called >> "recursive" and that allows one to lock the same mutex multiple times >> from the same thread. >> >> Good info on the terminology can be found here: >> http://www.boost.org/doc/html/thread/concepts.html >> under locking strategies. >> >> From reading some of the boost lists it seems that making a >> non-recursive mutex (like the normal pthread_mutex is) is quite hard on >> Windows. Boost neatly sidetsteps the issue by making it the programmer's >> problem: >> " >> In general a mutex object with an unspecified locking strategy is >> unsafe, and it requires programmer discipline to use the mutex object >> properly. However, this strategy allows an implementation to be as fast >> as possible with no restrictions on its implementation. This is >> especially true for portable implementations that wrap the native >> threading support of a platform. For this reason, the classes >> boost::mutex, boost::try_mutex and boost::timed_mutex use this locking >> strategy despite the lack of safety. >> " >> >> Boost uses critical sections on Windows and this is the same position we >> are in now in terms of the differences between Linux and Windows. The >> issue therefore is: Can we assume that all the code in OpenThreads/OSG >> that relies on OpenThreads::Mutex adheres to this magical "programmer >> discipline". It might, but I don't know how to even check. Were other >> parts of code written with only non-recursive mutexes in mind? >> >> Alternatives for creating a non-recursive mutex on Windows are: >> * InterLockedExchange and various ways of spinning (like the old >> OpenThreads code). Seems hard to get right and sched delays are almost >> unavoidable. >> >> * InterLockedExchange and an event. This looks quite neat and is used by >> pthreads for win32 (see http://sourceware.org/pthreads-win32/) >> >> * more ... e.g. May 2007 article >> http://www.ddj.com/dept/cpp/199203083 >> "Developing Lightweight, Statically Initializable C++ Mutexes" >> >> I hope I'm not kicking up a storm over nothing, but it just seems that a >> mutex issue can cause all sorts of funnies with initialisation, shutdown >> and multi-threading. >> >> regards >> jp >> >> >> Paul Martz wrote: >> > Yep, the CRITICAL_SECTION code was my change. There were bugs >> reported in >> > the old code, and moving to CRITICAL_SECTION seemed like a wonderful >> > simplification. I admit I didn't read the OpenThreads documentation, >> so was >> > not aware that a thread should block itself in this case. >> CRITICAL_SECTION >> > doesn't support that, as far as I know. It does block other threads >> though. >> > >> > My apologies, >> > -Paul >> > >> > >> >> -----Original Message----- >> >> From: [EMAIL PROTECTED] >> >> [mailto:[EMAIL PROTECTED] On Behalf Of >> >> J.P. Delport >> >> Sent: Thursday, May 31, 2007 3:16 AM >> >> To: osg users >> >> Subject: Re: [osg-users] OpenThreads::Mutex win32 vs pthread >> >> inconsistencies >> >> >> >> Hi, >> >> >> >> Robert Osfield wrote: >> >>> Hi J.P. >> >>> >> >>> Must admit I haven't used trylock in the OSG which is >> >> possibly why we >> >>> haven't hit upon this issue before. >> >> The same actually happens with lock() on win32 with >> >> USE_CRITICAL_SECTION. I just used trylock() in the example to >> >> show the return value problem. >> >> >> >> current svn would happilly complete the following: >> >> >> >> for (int i=0;i<10;i++) { >> >> mymutex.lock(); >> >> } >> >> >> >> without any unlocks. I think it would only block if lock() is >> >> actually called from a different thread, but this is still >> >> not the pthread behaviour. >> >> >> >> jp -- This message is subject to the CSIR's copyright, terms and conditions and e-mail legal notice. Views expressed herein do not necessarily represent the views of the CSIR. CSIR E-mail Legal Notice http://mail.csir.co.za/CSIR_eMail_Legal_Notice.html CSIR Copyright, Terms and Conditions http://mail.csir.co.za/CSIR_Copyright.html For electronic copies of the CSIR Copyright, Terms and Conditions and the CSIR Legal Notice send a blank message with REQUEST LEGAL in the subject line to [EMAIL PROTECTED] This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. MailScanner thanks Transtec Computers for their support. _______________________________________________ osg-users mailing list osg-users@openscenegraph.net http://openscenegraph.net/mailman/listinfo/osg-users http://www.openscenegraph.org/
