Threads

Wrestling With Concurrency - Scala Exchange 2012

I was very fortunate to join the London Scala Exchange conference over the last two days. A good range of quality talks were offered - some thought provoking, some highly entertaining. And most wrestled to some extent with concurrency. It seems that Scala is not yet at ease with itself in its concurrency model. The root of the issue is the JVM: threads are very expensive and limited to small numbers (say, 30).

BlockingQueues and Communicating Sequential Processes

A particularly important objective for developers producing of concurrent systems is to produce designs that always give consistent results and cannot deadlock (see The Four Horsemen on why this can be difficult). Since Java 1.5, the Java API has included the java.util.concurrent package, which contains a range of classes to support thread synchronisation, communication and safe sharing of data. This Java5 API enhancement introduced blocking queues for passing messages between threads, and with this it has been possible to write concurrent Java applications that benefit from decades of theoretical progress in how to design deadlock-free systems.