|
Boost Users : |
From: Howard Hinnant (hinnant_at_[hidden])
Date: 2008-07-25 13:13:15
On Jul 25, 2008, at 12:11 PM, Anthony Williams wrote:
> "Peter Dimov" <pdimov_at_[hidden]> 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
Boost-users list run by williamkempf at hotmail.com, kalb at libertysoft.com, bjorn.karlsson at readsoft.com, gregod at cs.rpi.edu, wekempf at cox.net