What happens to Mutex when the thread which acquired it exits?

Question

Suppose there are two threads, the main thread and say thread B(created by main). If B acquired a mutex(say pthread_mutex) and it has called pthread_exit without unlocking the lock. So what happens to the mutex? Does it become free?

Cason

Answer 1

nope. The mutex remaines locked. What actually happens to such a lock depends on its type, You can read about that here or here

Allegra

Whoa, a 'mutex' that doesn't have thread affinity? No "abandoned" error status? – Rabies

@Hans: In general, no. A normal mutex need not even be aware of which thread locked it; having to obtain and store this information would make it needlessly slow. And of course, how could the implementation permanently reserve the id of a dead thread and prevent its reuse without running out of ids? POSIX provides specialized robust mutexes which you can create if you need this kind of functionality, but they will typically be considerably slower and use considerably more resources (likely both userspace and kernelspace). – Icaria

So a thread that tries to acquire a mutex it already owns will deadlock itself? Tough programming. Any kind of re-entrant locking in pthreads? – Rabies

@Hans: Certainly: pthread_mutexattr_settype(PTHREAD_MUTEX_RECURSIVE) – Allegra

@Hans: You need a recursive mutex for that. Plain mutexes are not recursive. The need for recursive mutexes is usually a sign that your code is holding locks for way too long and will have very bad contention under load. – Icaria

this link is broken..pls change it – Scabbard

Answer 2

If you created a robust mutex by setting up the right attributes before calling pthread_mutex_init, the mutex will enter a special state when the thread that holds the lock terminates, and the next thread to attempt to acquire the mutex will obtain an error of EOWNERDEAD. It is then responsible for cleaning up whatever state the mutex protects and calling pthread_mutex_consistent to make the mutex usable again, or calling pthread_mutex_unlock (which will make the mutex permanently unusable; further attempts to use it will return ENOTRECOVERABLE).

For non-robust mutexes, the mutex is permanently unusable if the thread that locked it terminates without unlocking it. Per the standard (see the resolution to issue 755 on the Austin Group tracker), the mutex remains locked and its formal ownership continues to belong to the thread that exited, and any thread that attempts to lock it will deadlock. If another thread attempts to unlock it, that's normally undefined behavior, unless the mutex was created with the PTHREAD_MUTEX_ERRORCHECK attribute, in which case an error will be returned.

On the other hand, many (most?) real-world implementations don't actually follow the requirements of the standard. An attempt to lock or unlock the mutex from another thread might spuriously succeed, since the thread id (used to track ownership) might have been reused and may now refer to a different thread (possibly the one making the new lock/unlock request). At least glibc's NPTL is known to exhibit this behavior.

Icaria