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...
(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.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk