Subject: Re: [boost] [interprocess] locked mutex and process killed
From: Dmitry Goncharov (dgoncharov_at_[hidden])
Date: 2009-03-25 06:19:14
Kim Barrett wrote:
> At 11:40 AM +0300 3/25/09, Dmitry Goncharov wrote:
>> Even in this situation you can do something. After a thread (or a
>> process) which holds a mutex locked gets killed any attempt to unlock
>> the mutex
>> will (and should) fail with EPERM.
> Per POSIX, if the mutex type is PTHREAD_MUTEX_NORMAL, unlock by
> non-owner invokes undefined behavior.
>> To resume using the mutex you can initialize it again. In other
>> words, you can invoke pthread_mutex_init() on this mutex. This will
>> unlock the mutex for you.
> Again per POSIX, reinitializing an initialized mutex invokes undefined
> behavior, as does destroying a locked mutex.
> Just as an example of the problems, what happens to all the threads that
> were blocked waiting for the mutex that was just reinitialized out from
> under them.
>> This is sort of a dirty trick. If a thread had a mutex locked when it
>> was killed it is very likely that the data (that the mutex protects)
>> is in some inconsistent state. So, besides unlocking the mutex (by
>> the means of pthread_mutex_init()) you also have to restore the data.
> There are applications where that kind of roll-back is possible and even
> necessary, just perhaps tricky to write. That's why there is interest in
> so-called "robust" mutexes.
You are exactly right. Your points prove that this is a dirty trick.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk