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

From: Peter Dimov (pdimov_at_[hidden])
Date: 2008-07-25 13:37:56

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