The actor model is a pretty nice abstraction to reason about completely independent entities that interact purely by exchanging messages. However, for software development, some see the pure actor model as too fine-grained and too restrictive exposing many of the low-level issues such as data races again on a higher level again, and thereby forgoing some of its conceptual benefits.
We see the actor model also as a nice way to think about problems. However, we consider them in a more coarse-grained version. For us, actors are not on the level of objects but rather on the level of groups of objects like in the communicating event loop model as proposed by the E language and AmbientTalk. On this level, actors represent larger components, or subsystems if you will, and on multicore systems the question arises how parallelism and resource sharing can be achieved in a safe and efficient manner, without sacrificing the actor model’s (and communicating event loop model’s) nice properties such as freedom of deadlocks and low-level data races.
With the recently published paper below, Joeri took the lead on developing a first idea in the direction of managing shared state in the context of a language based on communicating event loops. The paper is an extension of an earlier workshop paper, and since then, we developed the ideas already further and devised complementary solutions to cover a wider set of uses cases. Still, I think the paper is interesting in its own right, and also defines the semantics of the approach in a formal, and thereby less ambiguous manner.
The actor model is a concurrency model that avoids issues such as deadlocks and data races by construction, and thus facilitates concurrent programming. While it has mainly been used for expressing distributed computations, it is equally useful for modeling concurrent computations in a single shared memory machine. In component based software, the actor model lends itself to divide the components naturally over different actors and use message-passing concurrency for the interaction between these components. The tradeoff is that the actor model sacrifices expressiveness and efficiency with respect to parallel access to shared state.
This paper gives an overview of the disadvantages of the actor model when trying to express shared state and then formulates an extension of the actor model to solve these issues. Our solution proposes domains and synchronization views to solve the issues without compromising on the semantic properties of the actor model. Thus, the resulting concurrency model maintains deadlock-freedom and avoids low-level data races.