Boost logo

Boost :

From: Alexander Terekhov (terekhov_at_[hidden])
Date: 2004-07-13 09:37:40

Peter Dimov wrote:
> That's how Boost.Threads behaves, but (AFAICS) it doesn't protect itself
> against a thread switch and lock immediately after freeing the mutex for the
> wait, so it doesn't meet the "correctly" requirement. ;-)

I think it saves the lock count on the stack prior to releasing
internal "real" [non-recursive, in a way, because it's never used
recursively] mutex and restores the count on exit from cv.wait
after acquiring the "real" mutex. In a way, the scheme is really
similar to:

Per-thread flags can be used to turn nonrecursive locks into 
recursive ones.
key - tsd flag key 
lock - mutex (non-recursive lock)
count - unsigned
init {
  count = 0;
destroy {
lock {
  if (!tsd::get(&key)) { 
    tsd::set(&key, true); 
    lock.acquire();  // assume throw()-nothing
    count = 1;
  else {
unlock {
  if (!--count ) {
    lock.release(); // throw()-nothing
    tsd::set(&key, false); 
Note that if you need "posix safety" with respect to 
unlock/destroy of this lock, "tsd::set(&key, false);" 
shall be done before "lock.release();" (and of course 
the underlying nonrecursive lock itself shall be safe 
with respect to unlock/destroy).
where you just need to save-on-stack-and-reset/restore the lock 
count before-cv.enter_wait()/after-cv.exit_wait().
The problem I meant before was something else (don't recall now).

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