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/
