Message-ID: <1734706828.28499.1394352879327.JavaMail.firstname.lastname@example.org> Subject: Exported From Confluence MIME-Version: 1.0 Content-Type: multipart/related; boundary="----=_Part_28498_1519581736.1394352879326" ------=_Part_28498_1519581736.1394352879326 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Content-Location: file:///C:/exported.html
STM is one of the promising concepts that aim to enable developers to wr= ite safe concurrent code. Several promising open source JVM-based implement= ations have appeared recently - (http://multiverse.c= odehaus.org/overview.html, http://code.google.com/p/deuce/, http://akkasource.org/). As an initial part of the assignment the e= xisting options should be investigated in order to build a suitable STM str= ategy for the GPars project. A second part of the assignment would be to im= plement a Groovy wrapper around the chosen solution, integrating smoothly S= TM into Groovy and the GPars library as well as providing an intuitive API = or a set of DSLs.=20
The distinction between single-VM concurrency and concurrency among dist= ributed nodes is becoming blurred. Actors can be distributed across multipl= e nodes in a network, dataflow variables and channels can transport values = across the single-machine boundary as well as the state preserved by agents= can reside on a particular place in the network and may need to be accesse= d from other places. As part of this assignment the participant would desig= n and implement remoting for actors, agents and dataflow channels. Ideally = remoting should not have impact on the existing API, should be pluggable to= leverage different communication protocols and should be implemented as an= optional add-on to limit performance and memory overhead when single-machi= ne concurrency is used.