Message-ID: <1950358788.41796.1371679117379.JavaMail.email@example.com> Subject: Exported From Confluence MIME-Version: 1.0 Content-Type: multipart/related; boundary="----=_Part_41795_96712560.1371679117378" ------=_Part_41795_96712560.1371679117378 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.
The traditional thre=
ad-based concurrency model built into Java doesn't match well with the natu=
ral human sense for parallelism. While this was not a problem at times, whe=
n the level of parallelism in software was low and concurrency offered only=
limited benefits compared to sequential code, nowadays, 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 performance and hardware=
utilization with concurrent code.
Inevitably, for concurrent program= ming to be effective, the mental models of concurrent systems interactions = that people create in their heads have to respect the nature of human brain= s more than the wires on the chips. Luckily, such abstractions have been ar= ound for several decades, used at universities, in telephone switches, the = super-computing industry and some other inherently concurrent domains. The = current challenge for GPars is to bring these abstractions up to the mainst= ream software developers to help us solve our practical daily issues.
The framework provides straightforward Java or Groovy-based APIs to declar= e, which parts of the code should be performed in parallel. Collections can= have their elements processed concurrently, closures can be turned into co= mposable asynchronous functions and run in the background on your behalf, m= utable data can be protected by agents or software transactional memory.
For the common scenario that one or multiple results are calculated con= currently but need to be processed as soon as they are available, GPars mak= es it a breeze to correctly model this with Dataflow. Dataflow variables and channels gives you a handy abstra= ction of single-assignment multiple-read data elements, while dataflow oper= ators let you build efficient concurrent data-processing networks.
Th= e 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 t= his concept for Java and Groovy developers. With actors support you can qui= ckly create several independent Actors, which consume messages passed to th= em and communicate with other actors by sending them messages. You then bui= ld your solution by combining these actors into a communication network.
Please refer to the User Guide for a more extensive coverage of these topics or head over to the Demos.
Let the fun begin!
If you want to start experimenting = with GPars right away, use our Fast Track to get up and running within minu= tes.
Check out the User Voices to hear the opinions of people walking here = before you.
GPars is distribu= ted under the open-source=C2=A0Apache 2 License= a>. By using GPars you accept fully the terms stated in the license. For fu= ll details, please see the Apache 2 License d= ocument.