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