Having spent some actual time on a Java based multi-threaded project, I want to reflect.
My reflection is: Don’t ever use Java’s concurrency libraries in an agile project. At a high level this is for several reasons:
- People find multi-threading difficult to understand. If you have a learn a bunch of things on a project, things like this generate fear, and push it into the little group of “people who know”.
- Multi-threaded design using locks, synchronization, futures, etc is inherently unstable – e.g. a small change in requirements can invalidate a carefully put-together architecture. Essentially – if any code needs to know it is multi-threaded, you are going to have a hard time.
The trouble is, the concurrency libraries are so beguiling. They say (silently, in the back of your head) “hmmm – yes we know the synchronize keyword is wrong, so let’s use barriers and countdown latches instead”.
You’re doomed, doomed I tell you.
What’s the alternative? Well, CSP (concurrent sequential processes) model of computation is pretty clean. It defines a mechanism of communication that allows each process to be single threaded, and have NO side-effects except on channels that are injected into that process.
There are implementations for Java, and for .Net. The problem with these, of course, is that the existing (poor) concurrency primitives are still available in the language. So even if you use CSP you’ll have to worry about someone not getting it and creating a deadlock in your code.
BUT – in ruby this isn’t the case. No-one really uses the threading libraries in ruby because the VM isn’t multi-threaded. So we have an opportunity to head-off the varmints at the pass.
So – firstly – don’t make the situation worse. Secondly, let’s get some CSP goodness into the ruby world, and have the ruby VM support CSP in the next few releases. We can think about pi-calculus later.