Re: [boost] Re: Boost.Threads: Do we need all those mutexes?

From: Peter Dimov (pdimov_at_[hidden])
Date: 2004-07-13 06:26:56

Howard Hinnant wrote:
> 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.

This kind of answers my question. ;-)

See pthread_mutexattr_settype and PTHREAD_MUTEX_RECURSIVE. Note also that an
implementation is allowed to make the default pthread_mutex recursive; in
this case your users pay for the recursive overhead twice. Not that they
don't deserve it for using a recursive_mutex. ;-)

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

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