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.

Read this post by Alistair Cockburn on Design as Knowledge Acquisition.

Developing application software, which is what I’ve done for a decade, always involves learning — acquiring knowledge.  We have to learn about the problem space (the ‘domain’), proposed solutions, the goals of the software, and design technical architectures that will support the goals.  It is frequently the case that some areas are new, and involve lot of unknowns.  The old fashioned waterfall approach tried to tackle the problem of these unknowns by a long period of study of the problems, prior to making attempts to design solutions.  The idea was that more knowledge up front would lead to better designs, earlier.  This is actually mistaken.   Implementation design should begin with only just enough initial knowledge to get going.  Assumptions can be tested against reality in a more rapid fashion.  This leads more quickly to satisfactory solutions at lower costs.  Alistair’s post describes it in more detail.  Do read it!