Re: OpenThreads::Mutex win32 vs pthread inconsistencies
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 <jpdelport@...> 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: osg-users-bounces@...
>> >> [mailto:osg-users-bounces@...] 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
CallCentre@...
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.
RSS Feed