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