[Pharo-project] [ANN] A Unifying Mechanism for the Implementation of Concurrency Abstractions

Stefan Marr smalltalk at stefan-marr.de
Fri Mar 9 11:01:54 EST 2012

Added missing links below, thanks Nick for pointing it out.

On 09 Mar 2012, at 15:38, Stefan Marr wrote:

> Hi, beware the shameless plug:
> Our paper 
>                   Identifying A Unifying Mechanism for the
>                 Implementation of Concurrency Abstractions on
>                       Multi-Language Virtual Machines [1]
> introduces an ownership-based Meta-object Protocol (MOP) to enable the
> enforcement of the various concurrency semantics required by the different
> programming models discussed in literature.
> The prototypical implementation is done on top of Pharo 1.3 and available at
> SqueakSource3 [2] under the MIT license.
> You might be interested in it to experiment with new concurrent programming
> models. Typically, green threads are enough to be exposed to race conditions
> and other correctness problems. Thus, a CogVM is sufficient for experiments.
> RoarVM support is coming later, enabling experiments with the parallel aspects
> of these programming models as well.
> For the evaluation, we implemented a couple of concurrency models on top of
> it. Most notably, you can use Clojure-like agents, AmbientTalk-like actors,
> a basic CSP, Active Objects, and an STM that is a port of Lukas Renggli's
> work. These concurrency models work out of the box with the Metacello
> configuration given below (to the degree they were tested and benchmarked).
> You might also be interested in the AmbientTalkST implementation that was done
> as comparison as well as the direct port of Lukas' STM to Pharo 1.3 [3].
> Please see the paper [1] for an introduction to the MOP and an example how to
> use it to make objects immutable and implement Clojure's agents guaranteeing
> all required semantics.
> The paper's abstract:
>    Supporting all known abstractions for concurrent and parallel programming
>    in a virtual machines (VM) is a futile undertaking, but it is required to
>    give programmers appropriate tools and performance. Instead of supporting
>    all abstractions directly, VMs need a unifying mechanism similar to
>    Our survey of parallel and concurrent programming concepts identifies
>    concurrency abstractions as the ones benefiting most from support in a VM.
>    Currently, their semantics is often weakened, reducing their engineering
>    benefits. They require a mechanism to define flexible language guarantees.
>    Based on this survey, we define an ownership-based meta-object protocol as
>    candidate for VM support. We demonstrate its expressiveness by
>    implementing actor semantics, software transactional memory, agents, CSP,
>    and active objects. While the performance of our prototype confirms the
>    need for VM support, it also shows that the chosen mechanism is
>    appropriate to express a wide range of concurrency abstractions in a
>    unified way.
> The code can be loaded into a fresh Pharo 1.3 image [4] with the following
> Gofer expression. However, be aware this is experimental software.
> Furthermore, note that you will need to acknowledge changes to the Process
> class:
>      Gofer new
>          url: 'http://ss3.gemstone.com/ss/Omni';
>          package: 'ConfigurationOfOmni';
>          load.
>      (Smalltalk at: #ConfigurationOfOmni) loadTOOLS2012.
> As mentioned before, the paper gives some examples. The definition of 
> different concurrency semantics can be found in subclasses of OstDomain.
> Examples of how to use any of the existing concurrency models are either the
> unit tests, or the included benchmarks.
> Note that the MOP based implementation of AmbientTalkST does use the same
> class names. Thus, to use the ad-hoc implementation, you will need to load it
> into a different image:
>      Gofer new
>          url: 'http://ss3.gemstone.com/ss/Omni';
>          package: 'ConfigurationOfAmbientTalkST';
>          load.
>      (Smalltalk at: #ConfigurationOfAmbientTalkST) loadTOOLS2012.
> Similarly, the port of Lukas Renggli's STM to Pharo needs to be loaded 
> into a separate image, too. This version is not using our MOP:
>      Gofer new
>          url: 'http://ss3.gemstone.com/ss/LRSTM';
>          package: 'ConfigurationOfLRSTM';
>          load.
>      (Smalltalk at: #ConfigurationOfLRSTM) loadTOOLS2012.
> Acknowledgements:
> Thanks to Lukas for his STM implementation I used here. It was also a strong
> inspiration for my bytecode transformation approach.
> Best regards
> Stefan

[1] http://soft.vub.ac.be/~smarr/2012/03/identifying-a-unifying-mechanism-for-the-implementation-of-concurrency-abstractions-on-multi-language-virtual-machines/
[2] http://ss3.gemstone.com/ss/Omni.html
[3] http://ss3.gemstone.com/ss/LRSTM.html
[4] http://gforge.inria.fr/frs/download.php/29273/Pharo-1.3-13315.zip

Stefan Marr
Software Languages Lab
Vrije Universiteit Brussel
Pleinlaan 2 / B-1050 Brussels / Belgium
Phone: +32 2 629 2974
Fax:   +32 2 629 3525

More information about the Pharo-dev mailing list