[Pharo-project] [ANN] A Unifying Mechanism for the Implementation of Concurrency Abstractions
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 INVOKEDYNAMIC for JVMs. 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 -- Stefan Marr Software Languages Lab Vrije Universiteit Brussel Pleinlaan 2 / B-1050 Brussels / Belgium http://soft.vub.ac.be/~smarr Phone: +32 2 629 2974 Fax: +32 2 629 3525
Hi Stefan, =Our paper
Identifying A Unifying Mechanism for the Implementation of Concurrency Abstractions on Multi-Language Virtual Machines [1]
I'm really looking forward to digesting this. I'm been flirting with Clojure and have been enviously looking at their STM, so this sounds really interesting and potentially very timely for Pharo and Smalltalk. Thanks Nick
BTW I think you missed the link to you paper. Google found it at: http://soft.vub.ac.be/~smarr/downloads/tools12-smarr-dhondt-identifying-a-un... On 9 March 2012 15:26, Nick Ager <nick.ager@gmail.com> wrote:
Hi Stefan,
=Our paper
Identifying A Unifying Mechanism for the Implementation of Concurrency Abstractions on Multi-Language Virtual Machines [1]
I'm really looking forward to digesting this. I'm been flirting with Clojure and have been enviously looking at their STM, so this sounds really interesting and potentially very timely for Pharo and Smalltalk.
Thanks
Nick
Hi Nick: On 09 Mar 2012, at 16:26, Nick Ager wrote:
I'm really looking forward to digesting this. I'm been flirting with Clojure and have been enviously looking at their STM, so this sounds really interesting and potentially very timely for Pharo and Smalltalk.
For you, there might still be the stumbling block performance. My direct port of Lukas' STM [1] performs a bit better than the port of it on top of my abstractions. However, comparing to Clojure is not entirely fair, since Clojure only tracks explicit 'refs'. While we in Smalltalk do not have that concept, and need to track everything. Lukas originally did benchmarks also with Pier or Seaside or so, don't remember precisely. You might find something in [2]. Helvetia [3] includes also a port of the STM, so you might be able to get your hands on some benchmarks to see whether it is fast enough for you. Would be interested to hear whether it is fast enough in practice. Best regards Stefan [1] http://ss3.gemstone.com/ss/LRSTM.html [2] http://source.lukas-renggli.ch/transactional.html [3] http://scg.unibe.ch/research/helvetia -- Stefan Marr Software Languages Lab Vrije Universiteit Brussel Pleinlaan 2 / B-1050 Brussels / Belgium http://soft.vub.ac.be/~smarr Phone: +32 2 629 2974 Fax: +32 2 629 3525
btw, Stefan i can help mentoring the projects you proposed for GSoC -- Best regards, Igor Stasenko.
On 10 Mar 2012, at 18:26, Igor Stasenko wrote:
btw, Stefan i can help mentoring the projects you proposed for GSoC
Sure, you are welcome, as are others. Just didn't had time to coordinate anything. Am already happy that I was able to give Janko the input he needed. Thanks Stefan -- Stefan Marr Software Languages Lab Vrije Universiteit Brussel Pleinlaan 2 / B-1050 Brussels / Belgium http://soft.vub.ac.be/~smarr Phone: +32 2 629 2974 Fax: +32 2 629 3525
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 INVOKEDYNAMIC for JVMs.
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-th... [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 http://soft.vub.ac.be/~smarr Phone: +32 2 629 2974 Fax: +32 2 629 3525
participants (3)
-
Igor Stasenko -
Nick Ager -
Stefan Marr