[boost] Re: Boost.Threads: Do we need all those mutexes?

From: Alexander Terekhov (terekhov_at_[hidden])
Date: 2004-07-12 13:14:52

Peter Dimov wrote:
[...]
> Forget that <cthread> for a while, how about sharing your thoughts on the
> proposed elimination of the try/timed axis. ;-)

Oh yeah. ;-) In the past (before "swap_based_mutex"... having only 
something along the lines of old/current pthread-win32's mutex thing) 
and given PTHREAD_TIMEOUT_ALLOWED/PTHREAD_TIMEOUT_DISALLOWED (stuff
that was proposed--among other interesting "military" things--in 
1003.1d/D11 and was also ditched later), I had some reservations...

http://groups.google.com/groups?selm=3F096C73.6A3DCA60%40web.de
http://groups.google.com/groups?selm=3f0c0a3d%40usenet01.boi.hp.com
http://groups.google.com/groups?selm=3F0C0F9E.FACB8EA3%40web.de
(If you read this entire message read also 3F0E944B.68DB9DCA%40web.de)

----
The point is that a mere presence of timedlock() may slow down 
pthread_mutex_unlock(), for example. [reference to pthreads-win32]
----
but not now.
> 
> >>> I can't speak for the boost implementation (haven't carefully
> >>> studied it), but the Metrowerks implementation also supports
> >>> conditions operating on a recursive mutex.
> >>
> >> Interesting. I presume that this was a deliberate design decision.
> >
> > It has a precondition "lock.mutex()->locked() && lock.mutex()->
> > lock_count() == 1" (or something like that... brrrr, so many "lock"
> > things... "guard" would sound much better ;-) )
> 
> Does it? I think that the Boost implementation tries to operate "correctly"
> for lock_count() > 1, but I may have misread the code.
I meant windows thing that is used in Metrowerks [if I got Howard 
right] and pthread-win32. IIRC, I've "voiced objection" at the time 
the boost::condition and recursive locks were discussed here. Uhmm, 
can't find it... but here's something: ;-)
http://groups.google.com/groups?selm=3D484233.AD1E26E8%40web.de
regards,
alexander.