Thread Safety - Java Concurrency in Practice - page 27

2.3.2. Reentrancy
When a thread requests a lock that is already held by another thread, the requesting thread
blocks. But because intrinsic locks are reentrant , if a thread tries to acquire a lock that it
already holds, the request succeeds. Reentrancy means that locks are acquired on a per-thread
rather than per-invocation basis. [7] Reentrancy is implemented by associating with each lock
an acquisition count and an owning thread. When the count is zero, the lock is considered un-
held. When a thread acquires a previously unheld lock, the JVM records the owner and sets
the acquisition count to one. If that same thread acquires the lock again, the count is incre-
mented, and when the owning thread exits the synchronized block, the count is decre-
mented. When the count reaches zero, the lock is released.
Reentrancy facilitates encapsulation of locking behavior, and thus simplifies the development
of object-oriented concurrent code. Without reentrant locks, the very natural-looking code
in Listing 2.7 , in which a subclass overrides a synchronized method and then calls
the superclass method, would deadlock. Because the doSomething methods in Widget
and LoggingWidget are both synchronized , each tries to acquire the lock on the
Widget before proceeding. But if intrinsic locks were not reentrant, the call to su-