Re: [Boost-users] [boost.thread] destruction of condition variables

From: Howard Hinnant (hinnant_at_[hidden])
Date: 2008-07-25 13:51:25

On Jul 25, 2008, at 1:37 PM, Peter Dimov wrote:

> Howard Hinnant:
>
>> I believe if this were to happen then the mutex would be generally  
>> unusable even without considering condition variables.  We have this:
>>
>> A                     B
>> m.lock();            ...
>> ...                  ...
>> m.unlock();          m.lock();
>> ...                  m.unlock();
>> ...                  m.~mutex();
>>
>> If after unlocking a mutex, and knowing by design that no one else  
>> is trying to lock it, you're still not able to safely destruct it,  
>> then you're really stuck with a bad mutex.  The only way you could  
>> safely destruct it is by signaling the destructing thread that all  
>> other  threads had passed a certain point.  Such a signal would  
>> need a  condition variable, and thus another mutex... catch  
>> 22! :-) ... One / has/ to be able to safely destruct a mutex after  
>> unlocking it.
>
> Yep. But this is not easy to get right. Looking at
>
> http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2406.html#shared_mutex_imp
>
> and using its exclusive part as an example, thread A does:
>
> void
> shared_mutex::unlock()
> {
>   {
>   scoped_lock<mutex> _(mut_);
>   state_ = 0;
>   }
>   gate1_.notify_all();
> }
>
> If it's preempted right after mut_.unlock, thread B can go ahead  
> with lock/unlock/destroy, destroying gate1_. Thread A then resumes  
> and crashes. Unless I'm missing something. (FWIW, most of my mutex  
> implementations have the same problem, the above is just the first  
> mutex implementation link I found with a quick Google.)

Ouch! Cut to the quick! :-)

Bug report gratefully accepted. :-)

-Howard