Boost logo

Boost :

From: Howard Hinnant (hinnant_at_[hidden])
Date: 2004-07-12 19:12:29

On Jul 12, 2004, at 4:51 PM, Peter Dimov wrote:

>> That was the intent. But I stand corrected. I evidently got it wrong
>> except on Mac OS X where I do explicitly decrement the count to 0 of
>> the pthread_mutex during a wait (recursive mutex case only). Looks
>> like I need to dig back into this on other platforms...
> Doesn't this impose some overhead on your recursive_mutex, even if the
> user
> never takes advantage of this feature? (I have to admit that I don't
> have
> the slightest idea how is this possible to implement correctly.)

I'm not familiar with how a native pthread_mutex is made recursive.
But with a native non-recursive mutex, the added space overhead simply
to handle recursive locking was also sufficient to negotiate use with
condition variables without further space overhead needed just for the
condition variables. To support the condition variables, a little more
code is needed (maybe a dozen lines of C++) executed from within the
wait function, and maybe a dozen or so bytes of stack space within the
condition's wait function. Essentially the wait function saves the
state of the mutex before the wait, then frees it for the wait, then
restores the state of the mutex after the wait. With a non-recursive
mutex you do the same thing, except that the state of the mutex is so
much simpler: it is locked before and after the wait, and unlocked
during. So there is no need to store mutex "state" on the stack for a
non-recursive mutex.


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