Anthony Williams:

However, it is never safe to destroy any object whilst another thread might still be in a member function.

I believe that this is a "POSIX destruction safety" issue. POSIX CVs are supposed to support such code.

If you use your mutex to protect the notify too, everything will be fine.

I think that if the mutex doesn't offer "POSIX destruction safety", the code can still fail. Thread A may be unblocked and destroy the mutex while thread B is still in mutex::unlock. http://lists.boost.org/Archives/boost/2004/07/68477.php

On Jul 25, 2008, at 12:11 PM, Anthony Williams wrote:

"Peter Dimov" writes:

...

Anthony Williams:

...

However, it is never safe to destroy any object whilst another thread might still be in a member function.

I believe that this is a "POSIX destruction safety" issue. POSIX CVs are supposed to support such code.

POSIX CVs are supposed to support broadcast immediately before destroy. What we have here is the waiting thread doing the destruction, which is not guaranteed safe by POSIX, as far as I know.

...

...

If you use your mutex to protect the notify too, everything will be fine.

I think that if the mutex doesn't offer "POSIX destruction safety", the code can still fail. Thread A may be unblocked and destroy the mutex while thread B is still in mutex::unlock.

Hmm. You're probably right. If the notify was protected by the mutex this would require that the notifying thread was still in the unlock even when the waiting thread had woken, acquired the lock and released the lock. Though this is unlikely, it could happen. Ouch.

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. Or have I misunderstood the concern? -Howard

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

Ouch! Cut to the quick! :-) Bug report gratefully accepted. :-) -Howard

Martin Trappel <0xCDCDCDCD@gmx.at> writes:

I'm using some boost::condition with 1.34.1 on windows - is that also broken? (And what is broken anyways?)

To the best of my knowledge, 1.34.1 is not broken. "Broken" in this case means that signals may get lost, so even if there is a thread waiting, notify_one() may not wake it. Anthony -- Anthony Williams | Just Software Solutions Ltd Custom Software Development | http://www.justsoftwaresolutions.co.uk Registered in England, Company Number 5478976. Registered Office: 15 Carrallack Mews, St Just, Cornwall, TR19 7UL