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