GPars provides a lot of concepts to pick from. We're continuously building and updating a page that tries to help user choose the right abstraction for their tasks at hands.
Please, refer to the "Concepts compared":http://gpars.codehaus.org/Concepts+compared page for details.

To briefly summarize the suggestions, below you can find the basic guide-lines:

 # You're looking at a collection, which needs to be *iterated* or processed using one of the many beautiful Groovy collections method, like _each()_ , _collect()_ , _find()_ and such. Proposing that processing each element of the collection is independent of the other items, using GPars *parallel collections* can be recommended.

 # If you have a *long-lasting calculation* , which may safely run in the background, use the *asynchronous invocation support* in GPars. Since the GPars asynchronous functions can be composed, you can quickly parallelize complex functional calculations without having to mark independent calculations explicitly.

 # You need to *parallelize* an algorithm at hand. You can identify a set of *tasks* with their mutual dependencies. The tasks typically do not need to share data, but instead some tasks may need to wait for other tasks to finish before starting. You're ready to express these dependencies explicitly in code. With GPars *dataflow tasks* you create internally sequential tasks, each of which can run concurrently with the others. Dataflow variables and channels provide the tasks with the capability to express their dependencies and to exchange data safely.

 # You can't avoid using *shared mutable state* in your algorithm. Multiple threads will be accessing shared data and (some of them) modifying it. Traditional locking and synchronized approach feels too risky or unfamiliar. Go for *agents*, which will wrap your data and serialize all access to it.

 # You're building a system with high concurrency demands. Tweaking a data structure here or task there won't cut it. You need to build the architecture from the ground up with concurrency in mind. *Message-passing* might be the way to go.

 ## *Groovy CSP* will give you highly deterministic and composable model for concurrent processes. The model is organized around the concept of *calculations* or *processes*, which run concurrently and communicate through synchronous channels.

 ## If you're trying to solve a complex data-processing problem, consider GPars *dataflow operators* to build a data flow network. The concept is organized around event-driven transformations wired into pipelines using asynchronous channels.

 ## *Actors* and *Active Objects* will shine if you need to build a general-purpose, highly concurrent and scalable architecture following the object-oriented paradigm.

 Now you may have a better idea of what concepts to use on your current project. Go and check out more details on them in the User Guide.
 


