Message-ID: <2054940151.793684.1386717449626.JavaMail.email@example.com> Subject: Exported From Confluence MIME-Version: 1.0 Content-Type: multipart/related; boundary="----=_Part_793683_107707275.1386717449626" ------=_Part_793683_107707275.1386717449626 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Content-Location: file:///C:/exported.html
The GPars framework offers Java developers intuitive and safe wa= ys to handle Java or Groovy tasks concurrently. Leveraging the enormous fle= xibility of the Groovy programing language and building on proven= Java technologies, we aim to make concurrent programming for multi-core ha= rdware intuitive, robust and enjoyable.
GPars is a multi-paradigm concurrency framework, offering several mutual= ly cooperating high-level concurrency abstractions, such as Dataflow op= erators, Promises, CSP, Actors, Asynchr= onous Functions, Agents and Parallel Collections.
The traditional thread-based concurrency model built into Java doesn't m=
atch well with the natural human sense for parallelism. While this was not =
a problem at times, when the level of parallelism in software was low and c=
oncurrency offered only limited benefits compared to sequential code, nowad=
ays, with the number of cores on a single main-stream chip doubling almost =
every year, sequential code quickly looses ground and fails to compete in p=
erformance and hardware utilization with concurrent code.
Inevitably,= for concurrent programming to be effective, the mental models of concurren= t systems interactions that people create in their heads have to respect th= e nature of human brains more than the wires on the chips. Luckily, such ab= stractions have been around for several decades, used at universities, in t= elephone switches, the super-computing industry and some other inherently c= oncurrent domains. The current challenge for GPars is to b= ring these abstractions up to the mainstream software developers to help us= solve our practical daily issues.
The framework provides straightforward Java or Groovy-based APIs to decl= are, which parts of the code should be performed in parallel. Collections c= an have their elements processed concurrently, closures can be turned into = composable asynchronous functions and run in the background on your behalf,= mutable data can be protected by agents or software transactional memory.<= /p>
For the common scenario that one or multiple results are calculated conc= urrently but need to be processed as soon as they are available, GPars make= s it a breeze to correctly model this with Dataflow. Dataflow variables and channels gives you a handy abstrac= tion of single-assignment multiple-read data elements, while dataflow opera= tors let you build efficient concurrent data-processing networks.
The concept of Actors as an approac= h to organizing concurrent activities has recently gained new popularity (t= hanks to the Scala, Erlang, and other programming languages). GPars impleme= nts this concept for Java and Groovy developers. With actors support you ca= n quickly create several independent Actors, which consume messages passed = to them and communicate with other actors by sending them messages. You the= n build your solution by combining these actors into a communication networ= k.
Let the fun begin!= span>
If you want to start experimenting with GPars right away, use our Fast T= rack to get up and running within minutes.
Check out the User Voices to = hear the opinions of people walking here before you.