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.