News: A First Look at JSR 166: Concurrency Utilities

  1. A First Look at JSR 166: Concurrency Utilities (5 messages)

    Brian Goetz has written about JSR 166 which has refactored the good work in Doug Lea's util.concurrent library and packaged it as a standard part of the 1.5 Java Class Library, to become the java.util.concurrent package. He talks about the changes made to the JVM itself, new classes/methods, Concurrent vs. Synchronized, and Locks vs. Synchronization.


    "Concurrent vs. Synchronized

    The Hashtable class is thread-safe, whereas the HashMap class is not. So why was another thread-safe map -- ConcurrentHashMap -- needed, when we already have Hashtable (and Collections.synchronizedMap())? While both Hashtable and ConcurrentHashMap are thread-safe implementations of Map, Hashtable (and synchronizedMap) get their thread-safety from synchronizing every method. (Note that simply synchronizing every method does not, in general, render a class thread-safe). The result of synchronizing every method is that no operations on a Hashtable in different threads can overlap each other -- access to the Hashtable is effectively serialized. Such classes can become a scalability bottleneck, because one thread performing a long-running operation on a Hashtable can stall many other threads until that operation is finished.

    By contrast, classes such as ConcurrentHashMap are designed not only for thread safety, but for highly concurrent access. This means that multiple operations can overlap each other without waiting for a lock. In the case of ConcurrentHashMap, an unbounded number of read operations can overlap each other, reads can overlap writes, and up to 16 write operations can overlap each other. In most cases, read operations (Map.get) can proceed with no locking at all! (This is the result of some extremely careful coding, deep understanding of the Java Memory Model, and extensive peer review -- don't try this at home.) The naming convention ConcurrentXxx indicates a class that has been designed not only for thread safety, but for high performance and scalability under concurrent access."

    Read A First Look at JSR 166: Concurrency Utilities
  2. New concurrent utilities are realy great!!!
    We have developed similar (but not that great, sure) set of concurrent utilities to be shared among Java projects in our company, like blocking (priority) queues, thread pools, locks etc. Now we can switch to standard ones (and I hope more performant due to JVM hooks) in the future.

    What I miss in the java.util.concurrent package is something like key level lockable Map, i.e. Map whose keys can be locked. For example:
    LockableMap map = new LockableHashMap();
    try {
       Object value = map.get(key);
       if (value == null) {
          value = ...
          map.set(key, value);
    finally {

    This way many threads can access and modify a Map when accessing different keys, but all are serialized when accessing one particular key. This is usefull when populating caches and you do not want two reads that read the same entity to occur simultaneosly.
    This is the very same as the Tangosol's ConcurrentMap and too bad that Tangosol's concurrent Map and java.util.concurrent.ConcurrentMap has the same name.

    But, given the wast of locks and ConcurrentMap in JDK 1.5 I suppose it will not be hard to develop one.

  3. I'm very impressed with the quality of this JSR, especially the excellent JavaDoc package comments, appreciation of generics, and rich set of primitives (without disturbing the JVM specification). The new Condition interface is very interesting since it allows a monitor to be freely composed of arbitrary locks and wait sets. This might let a monitor decide which of many waiting threads to next grant its lock. It hints at the possibility of custom scheduling within an application.
  4. and rich set of primitives (without disturbing the JVM specification).

    Well, the story of the VM spec being the only spec relevant for a JVM is only partly true. Sure the VM spec hasn't been changed but a lot of APIs silently require the VM to do more:

    * clear Reference objects
    * allow direct access to NIO direct buffers
    * and now atomic operations on volatiles
    * ... ?

    More or less, the VM spec + sun.misc.Unsafe are what you need to implement an efficient VM.

    But anyways, this does not mean anything bad about the JSR. The guys have done a really awesome job. The concurrency utilities are my secret star in Tiger.
  5. Brian - the article monster[ Go to top ]

    This is really another great article from Brian. I am wondering how he can keep the article writing pace. His DeveloperWorks articles are even better and sometimes really low level. It seems he left the userspace coding (webmacro) and dived into the VM sphere ;-)
  6. Good article[ Go to top ]

    Brian's was a very good introductry article on the concurrency utils. Among the various new features being introduced in Tiger, generics and the like have merited a number of tutorials and articles, both from guys and Sun and outside, but for some reason the concurrency utils only got a mention - as "Doug Lea's concurrency utils are now a part of the JDK" - as if the assumption was anybody who could care about concurrency already knew and used Doug's concurrency utils. Brian, this article was sorely needed, and seeing as it is just a brief first look, I urge you to follow this up with more articles that could help introduce more "regular" java developers to the concurrency utils.