Concurrent Programming in Java

Updates for J2SE 5.0 (aka 1.5, Tiger)

Someday, I hope there will be a third edition of this book. But in the mean time, here is a quick guide to how language and library updates affect coverage in the second edition:

• Package java.util.concurrent (JSR166) includes versions of the utilities described in the book, plus some others. Some of the class names and APIs are different than book versions, but should be easy to figure out.
• Section 1.1.2.6 says that arranging uncaughtException handlers is one of the few reasons to use ThreadGroup. Now this can be done within class Thread itself, leaving one fewer reason to use ThreadGroup.
• Section 2.2.7.x on the Memory Model doesn't provide current details of the JSR133 spec revision. (The basic ideas still apply though.) One change that commonly arises in practice is that Section 2.2.7.4 and 2.4.1.2 should say that reading a volatile reference makes visible other changes to the referred object by the thread writing the reference. In particular, double-check idioms work in the expected way when references are declared volatile.
• Section 2.2.3 only implicitly mentions weakly-consistent iterators, which are used extensively in java.util.concurrent collections. They differ from fast-fail in that they promise to be thread safe, but don't promise whether you will see any updates made to the collection since the iterator was constructed (e.g., you might see an added element, or you might not).
• Section 2.4.4.2 on Optimistic Updates takes on added importance now that Java directly supports atomic updates (in package java.util.concurrent.atomic). This greatly expands the range of application of the basic ideas in this section, enabling construction of efficient nonblocking algorithms and data structures (some of which appear in java.util.concurrent).
• In Section 3.2.4.2, the precaution of adding an extra notify() on interruption is no longer necessary (it doesn't hurt though) because of spec clarifications made in JSR133. Additionally, several of the twisty constructions in Sections 3.2.3 and 3.7 can be avoided by using utilities in package java.util.concurrent.locks.
• The polling discussion and examples in Section 4.1.5 can use java.nio rather than the illustrated emulations.
• The Executor framework in java.util.concurrent includes more functionality than indicated in Section 4.1, and includes versions of Callables and Futures that are simpler to use than stated in Section 4.3.