Welcome to GPars - Groovy Parallel Systems
The GPars project offers developers new intuitive and safe ways to handle tasks concurrently, asynchronously, and distributed by utilizing the power of the Java platform and the flexibility of the Groovy language.
- Concurrent collection processing
- Asynchronous operations
- Fork/Join abstraction
- Actor programming model
- Dataflow concurrency constructs
- Agent - an mt-safe reference to mutable state
Project's main values
- Clever and clean design
- Elegant APIs
- Flexibility through meta-programming
- Application-level solutions that scale with number of cores
- Distribution through "scripting" - shipping groovy scripts over the wire
The framework provides straightforward Groovy-based APIs to declare, which parts of the code should be performed in parallel. Objects are enhanced with asynchronous methods like eachAsync(), collectAsync() and others, to perform collection-based operations in parallel based on the fork/join model. Also, closures can be turned into their asynchronous variants, which when invoked schedule the original closure for processing in an executor service. The library also provides several helper methods for running a set of closures concurrently.
The concept of Actors as an approach to organizing concurrent activities has recently gained new popularity (thanks to the Scala, Erlang, and other programming languages). GPars implements this concept for Java and Groovy developers. With actors support you can quickly create several independent Actors, which consume messages passed to them and communicate with other actors by sending them messages. You then build your solution by combining these actors into a communication network. Groovy actors do not depend on an exclusive thread. You can have much more actors than threads.
Actor do not necessarily need to reside on the same physical machine. Gpars supports (as of version 0.9) distributed actors, which may exchange message irrespective of their actual location in the network.
For the common scenario that one or multiple results are calculated concurrently but need to be processed as soon as they are available, GPars makes it a breeze to correctly model this Dataflow. Dataflow variables and streams gives you a handy abstraction of single-assignment multiple-read data elements.
Concurrency is all about managing state. If there is no mutable state, concurrency becomes a non-issue. However, as soon as we integrate with Java and it's libraries, we inherently deal with mutable state. What GPars adds to alleviate this situation is the concept of a Agent - a non-blocking mt-safe reference to mutable state that is inspired by "agents" in the Clojure language.
Let the fun begin!