17

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?

Victor Parmar
  • 5,719
  • 6
  • 33
  • 36
Sadish
  • 183
  • 1
  • 4

2 Answers2

17

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

SingleNegationElimination
  • 151,563
  • 33
  • 264
  • 304
  • 1
    Whoa, a 'mutex' that doesn't have thread affinity? No "abandoned" error status? – Hans Passant Dec 12 '10 at 22:10
  • 3
    @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). – R.. GitHub STOP HELPING ICE Dec 12 '10 at 22:18
  • 1
    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? – Hans Passant Dec 12 '10 at 22:51
  • 1
    @Hans: Certainly: `pthread_mutexattr_settype(PTHREAD_MUTEX_RECURSIVE)` – SingleNegationElimination Dec 12 '10 at 23:02
  • 1
    @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. – R.. GitHub STOP HELPING ICE Dec 13 '10 at 04:34
  • this link is broken..pls change it – Abhishek Gupta Dec 29 '12 at 10:38
16

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.

R.. GitHub STOP HELPING ICE
  • 208,859
  • 35
  • 376
  • 711