Explicit Locks - Java Concurrency in Practice - page 325

Listing 13.5. Interruptible Lock Acquisition.
13.1.3. Non-block-structured Locking
With intrinsic locks, acquire-release pairs are block-structured—a lock is always released in
the same basic block in which it was acquired, regardless of how control exits the block.
Automatic lock release simplifies analysis and prevents potential coding errors, but some-
times a more flexible locking discipline is needed.
In Chapter 11 , we saw how reducing lock granularity can enhance scalability. Lock striping
allows different hash chains in a hash-based collection to use different locks. We can apply
a similar principle to reduce locking granularity in a linked list by using a separate lock for
each link node , allowing different threads to operate independently on different portions of
the list. The lock for a given node guards the link pointers and the data stored in that node, so
when traversing or modifying the list we must hold the lock on one node until we acquire the
lock on the next node; only then can we release the lock on the first node. An example of this
technique, called hand-over-hand locking or lock coupling , appears in [CPJ 2.5.1.4].
13.2. Performance Considerations
When ReentrantLock was added in Java 5.0, it offered far better contended performance
than intrinsic locking. For synchronization primitives, contended performance is the key
to scalability: if more resources are expended on lock management and scheduling, fewer
are available for the application. A better lock implementation makes fewer system calls,
forces fewer context switches, and initiates less memory-synchronization traffic on the shared