Boost logo

Boost :

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)
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

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: ;-)

Boost list run by bdawes at, gregod at, cpdaniel at, john at