Towards an Actor-Based Concurrent Machine Model
Total Page:16
File Type:pdf, Size:1020Kb
Towards an Actor-based Concurrent Machine Model ∗ Hans Schippers Tom Van Cutsem Universiteit Antwerpen Vrije Universiteit Brussel Antwerpen, Belgium Brussels, Belgium hans.schippers@ua.ac.be tvcutsem@vub.ac.be y Stefan Marr Michael Haupt Robert Hirschfeld Vrije Universiteit Brussel Hasso Plattner Institute Hasso Plattner Institute Brussels, Belgium Potsdam, Germany Potsdam, Germany stefan.marr@vub.ac.be michael.haupt@hpi.uni- hirschfeld@hpi.uni- potsdam.de potsdam.de support thread-local behavior, which in turn is needed to implement several crosscutting constructs (e. g., cflow). ABSTRACT Adding concurrency support to delMDSOC involves three main tasks. First, the machine model has to be extended In this position paper we propose to extend an existing with concurrency primitives in a way compatible with the delegation-based machine model with concurrency primi- already present primitives for (mostly non-concurrent) MD- tives. The original machine model which is built on the con- SOC support. Second, it needs to be verified that the re- cepts of objects, messages, and delegation, provides support sulting machine model is sufficiently expressive in order to for languages enabling multi-dimensional separation of con- support different concurrency mechanisms as exhibited by a cerns (MDSOC). We propose to extend this model with an range of high-level languages. Finally, the model should be actor-based concurrency model, allowing for both true par- sufficiently powerful to allow for concurrency-related MD- allelism as well as lightweight concurrency primitives such SOC features such as thread-local aspects and cflow. as coroutines. In order to demonstrate its expressiveness, This position paper presents a first attempt to add con- we informally describe how three high-level languages sup- currency support to the delMDSOC machine model. As the porting different concurrency models can be mapped onto latter is object-based and relies on late-bound message dis- our extended machine model. We also provide an outlook patch (cfr. Sec. 2), a concurrency model that is based on on the extended model's potential to support concurrency- messages rather than shared state is preferable. Hence, the related MDSOC features. actors model [1] can serve as a source of inspiration. A more traditional model based on threads and locks does not 1. INTRODUCTION seem to be a good choice: it is deceivingly simple|problems The delegation-based delMDSOC machine model [7] has like starvation, deadlocks and race conditions frequently oc- good support for modularizing crosscutting concerns and cur. Moreover, an actor-based model using message passing hence for generally supporting programming languages en- is conceptually closer to the delMDSOC model as it pro- abling multi-dimensional separation of concerns (MDSOC). vides natural isolation of state in actors|a concept that is Its implementation, the delMDSOC kernel 1 [15] achieves in line with the recent success of multi-core architectures most of the features required to implement MDSOC pro- with processor-local memory. gramming languages. An important feature still missing is Compared to machine models proposed earlier, implemen- explicit concurrency support. This, however, is required to tation in hardware is not an issue. A parallel machine inter- ∗ face consisting of primitives sufficient for dataflow, shared Postdoctoral Fellow of the Research Foundation, Flanders memory, and message passing models is discussed in [5]. It (FWO) was designed keeping the tradeoffs for being realized in hard- y Funded by a doctoral scholarship of the Institute for the ware in mind. Today, this is not an adequate restriction any Promotion of Innovation through Science and Technology more. Instead, an implementation as part of a high-level in Flanders (IWT) 1 language virtual machine is desirable. Thus, we concentrate http://www.hpi.uni-potsdam.de/swa/projects/ on a conceptually clean model which fits to the delMDSOC delmdsoc/ model and disregard implementation complexity as an im- portant design consideration. Throughout this paper, we first introduce the delMDSOC model in Sec. 2 before we present the concurrency model we propose for integration with delMDSOC in Sec. 3. Next, in Sec. 4, we discuss a possible translation process to the c ACM, 2009. This is the author’s version of the work. It is posted here extended delMDSOC for several high-level languages with by permission of ACM for your personal use. Not for redistribution. The support for different kinds of concurrency models. Sec. 5 definitive version was published in ICOOOLPS’09 July 6, 2009, Genova, provides an outlook on the model's suitability concerning Italy http://doi.acm.org/10.1145/1565824.1565825. support for concurrency-related MDSOC features. Finally, 3. AN ACTOR-BASED MACHINE MODEL obj ... actual_obj ... foo = (...) foo = (...) Our proposed machine model with explicit concurrency bar = (..., self foo, ...) obj bar = (..., self foo, ...) baz = (...) baz = (...) support is based on the well-known actor model of com- putation [1]. In contrast to multithreading, actors are a (a) (b) message-passing-based concurrency model that is more in Figure 1: An object is represented as a combination line with the principles of object-oriented computing. of a proxy and the actual object. Actors were originally formulated as an extension of a functional programming language with three primitives to create new actors, send (asynchronous) messages to them, and to change the actor's behavior in how it will respond to the paper is concluded and future work discussed in Sec. 6. future messages. Messages are buffered in an actor's mail- box. This model of \functional" actors is still used in well- known languages such as Erlang [3], but has also been rec- 2. A MACHINE MODEL FOR MDSOC onciled in many ways with stateful object-oriented program- In this section we briefly describe the delMDSOC ma- ming also known as \active objects" as used in ProActive [4]. chine model originally introduced in [7]. Based on the no- The pure actor model makes no distinction between ac- tions of objects, messages and delegation, its original appli- tors and regular objects. In a sense, all objects are actors. cation domain is to serve as a compilation target for high- In practice, forcing all objects to be active is not always de- level languages dealing with the modularization of crosscut- sirable, neither from a programming point-of-view nor from ting concerns. Such concerns cannot be modularized in a an implementation point-of-view. More concurrency leads program's dominant decomposition, and hence appear scat- to more non-determinism in a system. If it can be avoided, tered throughout several unrelated modules. Examples of it should be for the sake of simplicity. MDSOC paradigms trying to address this issue are aspect- The E language (with its predecessors) [13] was the first oriented programming (AOP) [12] and context-oriented pro- to reconcile actors with objects. In E, actors are not \ac- gramming (COP) [9]. tive objects" but rather vats (containers) of regular objects. Core features of the model pertain to the representation An actor contains any number of regular objects, shielding of application entities and that of join points, which are them from unwanted concurrent modifications. Each actor points in the execution of a program where functionality still has its own message queue and its own thread of con- dispatch occurs. The latter are consistently regarded as loci trol. Messages that arrive in such message queue are not of late binding organized along multiple dimensions. Each directed at the actor itself but rather to a particular object dimension represents one possible way to choose a particu- contained within the actor. All objects in an actor share lar binding of a piece of functionality to a join point, e. g., the actor's message queue. Objects within the same actor the current object, the target of a method call, the invoked can communicate using familiar synchronous method invo- method, or the current thread. cations. Objects within different actors can only communi- The model assumes a prototype-based object-oriented en- cate asynchronously, as in the actor model. vironment in which objects are consistently represented as An important feature of this model is that actors can share \seas of fragments" [14]: each object is visible to others via a mutable state (objects), but only the actor that contains proxy determining the object's identity. Messages sent to an the state (object) can access it synchronously. All other object are received by its proxy and delegated to the actual actors can only manipulate it asynchronously, by sending object, as displayed in Fig. 1. The model allows dynamic an asynchronous message to the object. This message is modification of this initial configuration by inserting and re- then executed by the actor containing the object. Shared moving additional proxy objects in between the proxy and state is thus supported without introducing locks avoiding its delegate object. This results in a chain of proxy objects many race condition and deadlock issues of traditional mul- (fragments) organized in a delegation chain, which collec- tithreading. tively constitute the whole object. A crucial property of Our concurrent machine model is based on E's model of delegation is that self remains bound to the original receiver concurrency, extended with lightweight concurrency support object, i. e., the proxy at the head of the delegation chain. in the form of coroutines. The abstract model is depicted in Classes are represented likewise: each class is a pair of Fig. 2. a proxy and an object representing the actual class. Each As in E, programs are composed of a number of actors. object references its class by delegating to the class proxy. The threads of control of these actors can execute in parallel, The granularity of the supported join point model is that so they can exploit multiprocessor concurrency. Similar to of message receptions.