Select Page

Recently I had the pleasure of two sessions on programming concurrency on the Java VM by Dr. Venkat Subramaniam, at a No Fluff, Just Stuff conference.  The presentations were based on his recent book, Programming Concurrency on the JVM.  Two very different approaches to programming concurrency were presented:  the Actor paradigm, and Software Transactional Memory (STM).

Multiple-core CPUs are having a big impact on application programming, because they increase parallelism, which brings out concurrency bugs in programs that are not correctly written.  Writing correct programs in a concurrent environment is very difficult.  Java has supported concurrency from the beginning with threads and synchronization.  But unfortunately it is incredibly difficult to write programs in Java that will execute correctly in concurrent environments.  On the contrary, it is incredibly easy to write incorrect programs without knowing it.  Why?  First, the object-oriented paradigm is all based on state, and the language facilitates access to shared state by multiple threads.   There is no support in the compiler or the runtime to detect concurrency problems.  Moreover, it is hard to write automated tests that prove correctness under concurrency.  If you don’t believe this, Venkat’s amusing presentation will convince you.  Except for very simple cases we cannot know by inspecting code or by writing tests that our Java code is correct, as long as we rely on the primitive support of synchronization and try/wait.

There are surprisingly few good sources of information for working application developers wanting to do concurrency well.  One of the first to address the issue was Doug Lea’s book, Concurrent Programming in Java, first published in 1999 and now in it’s third edition.  Lea’s book lead to the java.util.concurrent library being added to Java in Java 5, which I have used to improve my concurrent programs.  Brian Goetz came out in 2006 with the essential book, Java Concurrency in Practice, which dives deep into the workings of the Java memory model and gives practical examples for using java.util.concurrent classes to write thread-safe code.  This solution works, but Venkat calls the approach ‘synchronize and suffer’ because of its difficulty.   I learned from Venkat that the Java concurrent library has become the ‘assembly language’ for a new generation of open source APIs, some of which he covers in his recent book.  Here are some resources.

  • Scala has become popular for concurrent Java programming, in particular the Akka framework and its support for Actors.
  • A book on Akka futures is available from the author, Mike Slinn.
  • Clojure is a JVM language that features immutability and STM as first class language features.  Venkat demonstrated how to use clojure classes in Java source code to achieve STM in pure Java.
  • The GPars framework (pronounced ‘jeepers’) provides concurrency support in Groovy.  GPars is now in 1.0 beta and supports both Actors and STM.

To sum up, it was never easy to do, and now it is becoming crucial to get concurrency right on the JVM.  Although it requires considerable study, fortunately the field is starting to produce the literature and the APIs that working programmers need to get the job done.