Concurrent Programming in Java, Second Edition: Design Principles and Patterns


By: D. Lea
Published in: Addison Wesley, 2000

Summary: Assumes object-oriented background but little knowledge of concurrency. Chapter 1 provides a conceptual basis for concurrent object-oriented programming. The three subsequent chapters describe the use of concurrency constructs in Java.

Category: Concurrent Systems, Java Idioms

Assumes object-oriented background but little knowledge of concurrency. Chapter 1 provides a conceptual basis for concurrent object-oriented programming. The three subsequent chapters describe the use of concurrency constructs in Java.

Pattern: Method Adapters

Pages: 64-65, 150-151

To exercise "before" and "after" control on an activity, define a class whose sole purpose is to invoke a particular method on a particular object.

Pattern: Session

Pages: 101

A hand-off protocol ensures that at any point at most one actively executing method can access an object. Many hand-offs are structured as sessions in which objects are constructed that will be confined to a sequence of operations comprising a service.

Pattern: Double Check

Pages: 120-121

Category: Concurrent Systems, Java Idioms, Refactoring

When an illegal value has been read, reaccess the field under synchronization, determine its current value and take appropriate action. When locking causes liveness or performance problems, you can refactor the design using this pattern.

Pattern: Open Calls

Pages: 121-123, 287

Category: Concurrent Systems, Java Idioms, Refactoring

When you don't need to synchronize stateless parts of methods, use open calls or messages sent without holding locks. They eliminate bottlenecks but are useful only when clients know enough to use an approach that permits independent execution.

Pattern: Pass-Through Host

Pages: 125, 287

Category: Concurrent Systems, Java Idioms, Refactoring

When a class can be partitioned into independent subsets, refactor the Host class to produce Helper classes whose actions are delegated by the Host. In the most extreme case, a Pass-Through Host simply relays all messages using simple unsynchronized methods to a Helper.

Pattern: Copy-on-Write

Pages: 136-141

Category: Concurrent Systems, Java Idioms, Refactoring

In copy-on-write updates, state changes don't directly update fields. Instead, new representation objects are constructed and attached.

Pattern: Atomic Commitment

Pages: 140-141

Category: Concurrent Systems, Java Idioms, Refactoring

Replace assignment statements with an optimistic update technique that conditionally swaps in a new state representation only if the existing state representation is the one the caller expects.

Pattern: Open Containers

Pages: 142-145

Category: Concurrent Systems, Java Idioms, Refactoring

Most classes in concurrent programs undergo iterative refactorings to address locking issues. Ordered hierarchical locking techniques can be applied when you have layered containment but the parts are not hidden from other clients.

Pattern: Rollback

Pages: 163

In response to a failure in some part of the system, maintain state representations that allow a return to a consistent state.

Pattern: Roll-Forward

Pages: 164

When Rollback, as well as full continuation, is impossible or undesirable, push ahead conservatively to reestablish a guaranteed legal, consistent state.

Pattern: Multiphase Cancellation

Pages: 175-176

Try to cancel a task in the least disruptive manner first. If this fails, try a more disruptive strategy.

Pattern: Conflict Sets

Pages: 203-206

A conflict set contains pairs of actions that cannot co-occur. (1) For each action: (1) declare a counter to be set if the action is in progress; (2) isolate each action in a non-public method; (3) Write public versions of the methods in (2) to surround the action with "before" and "after" control.

Pattern: Readers and Writers

Pages: 207-210

Block Readers if there are waiting Writers. Waiting Writers are identified by the order in which the underlying JVM scheduler resumes unblocked threads. There are no downgrade mechanisms.

Pattern: Vetoable Changes

Pages: 261-263

A host with a set of objects that support vetoable set methods sends vetoable change events to listeners. If any listener responds with a veto, the set operation is cancelled.

Pattern: Thread-per-Message

Pages: 288-289

Concurrency can be introduced into one-way messaging designs by issuing a message in its own thread. This strategy improves throughput when multiple parallel tasks can run faster than a sequence of them.

Pattern: Worker Threads

Pages: 290-303

A worker thread or background thread (or thread pool) executes many unrelated tasks. Each worker thread continually accepts new Runnable commands from hosts, holding them in a Channel until they can be run.

Pattern: Event-Driven I/O

Pages: 299-303

Category: Concurrent Systems, Java Idioms, Refactoring

To handle many sessions without using many threads, refactor tasks into an event-driven style. (1) Isolate basic per-command functionality in a "run" task that reads one command and performs the associated action. (2) Define "run" to be repeatedly triggered by input or an I/O exception. (3) Manually maintain completion status.

Pattern: Flow Networks

Pages: 305-324

A flow network is a collection of objects that all pass one-way messages along paths from sources to sinks in one or more stages. Each stage is a producer and/or a consumer.

Pattern: Futures

Pages: 332-336

Futures are virtual data objects that automatically block when clients try to invoke their field accessors before their computation is complete. A Future acts as an IOU for a given data object.

Pattern: Fork/Join

Pages: 344-357

A parallel version of the divide-and-conquer technique from sequential approaches, implemented by forking and later joining tasks.