Let's set out a few assumptions before we get started:

# You know and use Groovy and Java: otherwise you'd not be investing your valuable time studying a concurrency and parallelism library for Groovy and Java.
# You definitely want to write your codes employing concurrency and parallelism using Groovy and Java.
# If you are not using Groovy for your code, you are prepared to pay the inevitable verbosity tax of using Java.
# You target multi-core hardware with your code.
# You appreciate that in concurrent and parallel code things can happen at any time, in any order, and more likely with than one thing happening at once.

With those assumptions in place, we get started.

It's becoming more and more obvious that dealing with concurrency and parallelism at the
thread/synchronized/lock level, as provided by the JVM, is far too low a level to be safe and comfortable.
Many high-level concepts, such as actors and dataflow have been around for quite some time: parallel
computers have been in use, at least in data centres if not on the desktop, long before multi-core chips hit
the hardware mainstream. Now then is the time to adopt these higher-level abstractions in the mainstream
software industry.  This is what *GPars* enables for the Groovy and Java languages, allowing Groovy and
Java programmers to use higher-level abstractions and therefore make developing concurrent and parallel
software easier and less error prone.

The concepts available in *GPars* can be categorized into three groups:

# _Code-level helpers_ Constructs that can be applied to small parts of the code-base such as individual algorithms or data structures without any major changes in the overall project architecture
## Parallel Collections
## Asynchronous Processing
## Fork/Join (Divide/Conquer)

# _Architecture-level concepts_ Constructs that need to be taken into account when designing the project structure
## Actors
## Communicating Sequential Processes (CSP)
## Dataflow
## Data Parallelism

# _Shared Mutable State Protection_ Although about 95% of current use of shared mutable state can be avoided using proper abstractions, good abstractions are still necessary for the remaining 5% use cases, when shared mutable state cannot be avoided
## Agents
## Software Transactional Memory (not fully implemented in GPars as yet)




