Re: [boost] [interprocess] locked mutex and process killed

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.

BR, Dmitry