JDK 5.0 is a huge step forward in developing concurrent Java classes and applications, providing concurrency building blocks for both novices and experts. This talk from JavaPolis (registration required) explores the new low-level concurrency utilities included in JDK 5.0, and examine their features and scalability. Prior to the release of JDK 5.0, the Java platform provided basic primitives for writing concurrent programs, but they were just that – primitive – and difficult to use properly. In addition to many new high-level concurrency utilities, such as semaphores, mutexes, barriers, thread pools, and thread-safe collections, JDK 5.0 also includes a number of JVM-level enhancements for concurrency, and a set of low-level concurrency utilities for developing highly scalable, nonblocking concurrent algorithms in Java. Even with built-in support for locking, it has not been practical to develop nonblocking concurrent algorithms in Java prior to JDK 5.0. With JVM support for accessing hardware-provided concurrency instructions (such as CAS) and the atomic variable classes provided in java.util.concurrent.atomic, it is now possible to develop highly scalable, wait-free, lock-free classes in Java.

I find the concurrency package very useful indeed but I find it amazing that I don't get any feedback on most the JDK (possible) bugs I reported, including a critical bug I reported on Thu May 26 02:50:20 MDT 2005: look for "LinkedBlockingQueue loses elements" at http://b28a827013ae11da8cd60800200c9a66.blogspot.com/. Never got any feedback on this bug or the other issues described there in my ad hoc blog. I also suggested a solution to fix the very unintuitive way ThreadPoolExecutor works at http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6233235 on 12-DEC-2005. Of course, this problem is already well known - perhaps fixed in jdk 6? For the LinkedBlockingQueue a possible fix was suggested to me by someone on forum.java.sun.com.

Back in 1997 I developed a library for developing concurrent programs using the Occam style channel communication as my final year uni project. http://www.cs.kent.ac.uk/projects/ofa/jcsp0-5/ The OCCAM approach gives a nice abstraction for the commincation and syncrhonization between threads as you comminicate via channels rather than having to worry about semaphores or locking

Concurrency utilities are very low level. To take advantage of concurrent algorithms in multi-processors environment. It is easier to use something higher level like Javolution ConcurrentContext (it uses an internal pool of concurrent threads, one per processor to accelerate concurrent algorithms).