In computer science, a reentrant mutex is a mutual exclusion, recursive lock mechanism. In a reentrant mutex, the same thread can acquire the lock multiple times. However, the lock must be released the same number of times or else other threads will be unable to acquire the lock. It has some similarities to a counting semaphore.
Recursive locks (also called recursive thread mutex) are those that allow a thread to recursively acquire the same lock that it is holding. Note that this behavior is different from a normal lock. In the normal case if a thread that is already holding a normal lock attempts to acquire the same lock again, then it will deadlock. Recursive locks behave exactly like normal locks when another thread tries to acquire a lock that is already being held. Note that the recursive lock is said to be released if and only if the number of times it has been acquired matches the number of times it has been released by the owner thread. Many operating systems do not provide these recursive locks natively. Hence, it is necessary to emulate the behavior using primitive non-recursive mutexes (locks).
A big form of criticism on recursive mutexes is that when used in combination with condition variables, the semantics are not clearly defined. Say, the condition variable would not recursively unlock the mutex, the system could run into a deadlock. On the other hand, if the mutex would be recursively unlocked, it would unlock all critical sections, even though simple inspection of code wouldn't reveal this. Therefore several implementations, such as the mutexes and condition variables used inside the FreeBSD kernel, don't allow waiting on a condition variable if the calling process has acquired more than one lock.
The Java language's native synchronization mechanisms have used recursive locks since Java's inception in about 1997. A lock is syntactically just a block of code with the 'synchronized' keyword preceding it and any Object reference in parentheses that will be used as the mutex. Inside the synchronized block, the given object can be used as a condition variable by doing a wait(), notify(), or notifyAll() on it. Thus all Objects are both recursive mutexes and condition variables. The newer Java versions provide additional primitives in the form of AtomicIntegers and AtomicBooleans and so on, which are lower-level and faster, and which can be used to construct spin-lock types of structures that allow multi-core programming, where mutexes and condition variables fail.
Example
- Thread A calls function F which acquires a reentrant lock for itself before proceeding
- Thread B calls function F which attempts to acquire a reentrant lock for itself but cannot due to one already outstanding, resulting in either a block (it waits), or a timeout if requested
- Thread A's F calls itself recursively. It already owns the lock, so it will not block itself (deadlock)
- Thread B's F is still waiting, or has caught the timeout and worked around it
- Thread A's F finishes and releases its lock
- Thread B's F can now acquire a reentrant lock and proceed if it was still waiting
