Reentrant mutex

[1] In pseudocode, that is the following situation: Given these definitions, the function call lock_and_call(1) will cause the following sequence of events: Replacing the mutex with a recursive one solves the problem, because the final m.lock() will succeed without blocking.

W. Richard Stevens notes that recursive locks are "tricky" to use correctly, and recommends their use for adapting single-threaded code without changing APIs, but "only when no other solution is possible".

[2] The Java language's native synchronization mechanism, monitor, uses recursive locks.

Syntactically, a lock is 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.