Avoiding Liveness Hazards - Java Concurrency in Practice - page 249

lems like those in Listing 10.5 is the use of synchronized methods instead of smaller
synchronized blocks for reasons of compact syntax or simplicity rather than because the
entire method must be guarded by a lock. (As a bonus, shrinking the synchronized block
may also improve scalability as well; see Section 11.4.1 for advice on sizing synchron-
ized blocks.)
Strive to use open calls throughout your program. Programs that rely on open calls are far
easier to analyze for deadlock-freedom than those that allow calls to alien methods with locks
held.
Restructuring a synchronized block to allow open calls can sometimes have undesirable
consequences, since it takes an operation that was atomic and makes it not atomic. In many
cases, the loss of atomicity is perfectly acceptable; there's no reason that updating a taxi's
location and notifying the dispatcher that it is ready for a new destination need be an atomic
operation. In other cases, the loss of atomicity is noticeable but the semantic changes are still
acceptable. In the deadlock-prone version, getImage produces a complete snapshot of the
fleet locations at that instant; in the refactored version, it fetches the location of each taxi at
slightly different times.
In some cases, however, the loss of atomicity is a problem, and here you will have to use
another technique to achieve atomicity. One such technique is to structure a concurrent ob-
ject so that only one thread can execute the code path following the open call. For example,
when shutting down a service, you may want to wait for in-progress operations to complete
and then release resources used by the service. Holding the service lock while waiting for
operations to complete is inherently deadlock-prone, but releasing the service lock before the
service is shut down may let other threads start new operations. The solution is to hold the
lock long enough to update the service state to “shutting down” so that other threads wanting
to start new operations—including shutting down the service—see that the service is unavail-
able, and do not try. You can then wait for shutdown to complete, knowing that only the shut-
down thread has access to the service state after the open call completes. Thus, rather than
using locking to keep the other threads out of a critical section of code, this technique relies
on constructing protocols so that other threads don't try to get in.
10.1.5. Resource Deadlocks
Just as threads can deadlock when they are each waiting for a lock that the other holds and
will not release, they can also deadlock when waiting for resources.