RSS Feed.
These days when the average programmer thinks of handling concurrency and parallelism, they usually think "threads". This then leads to horrible synchronization issues and worrying about locks, monitors and semaphores. And in the end the programs generally have non-determinstic errors. At the heart of the problem is shared memory.
Many, many years ago, models of concurrency were proposed -- cf. Actor Model, CSP (Communicating Sequential Processes) -- and these are seeing a huge resurgence of interest with the pandemic parallelism now available on all computers due to the Multicore Revolution. Erlang's parallelism is based on the Actor Model. Scala uses the Actor Model as its mechanism for dealing with concurrency and its subset parallelism. Clojure also makes use of the Actor Model. CSP is springing up with JCSP, Python CSP, etc. Java though is still stumbling along trying to harness parallelism with threads. Until now.
The Groovy community has been discussing what to do about harnessing parallelism for a year or two now. Last year Václav Pech acted and started the GParallelizer project. This was inspired by the work in Scala on the Actor Model and focused on using Groovy as a base on which to write a domain specific language (DSL) to be a coordination language managing parallelism. Till a couple of months ago this had been a one-developer project. Now though it has become a serious, and probably a strategic, multi-developer project.
Rebranded GPars, and now a Codehaus project, Václav Pech is leading an effort -- which includes your current author -- that will undoubtedly see Groovy used as a way of specifying the concurrency and parallelism architecture for many a Java system. Parallelism on the JVM just got very Groovy.