Actalk(ID:1451/act006)Briot, 1989. Smalltalk-based actor language. Structures: Related languages
References: We show how to extend the Actalk kernel into various extensions to define the basic Actor model of computation, higher level programming constructs such as the 3 types of message passing (asynchronous, synchronous, and eager) proposed in the ABCL/1 programming language, and some distributed architecture. All these examples are constructed as simple extensions of our kernel model. ps Extract: Introduction Introduction The Smalltalk-80 language is the best example of Object-Oriented Programming (OOP) languages. One important characteristic of Smalltalk-80 we will focus on in this paper is its sequentiality. The text of a method body is a sequence of expressions, which are evaluated sequentially. The Smalltalk-80 computation model is based on a single thread of activity which is passed among objects in a call/return fashion when sending messages. The introduction of processes into the language allows multiple activities but objects remain passive by nature. The process level is also unfortunately orthogonal with the object level. As a consequence combination of these two styles is uneasy as well as unsafe. If inside two distinct processes two messages are sent to a same object, there is no guarantee in the composition of the messages. If there is some state change (assignment of variables) in the bodies of the methods activated, this could lead to chaos. Semaphores are provided in Smalltalk-80 as tools for synchronization. But semaphores are very low level tools. The nature of processes and semaphores, used to synchronize processes and their accesses to shared data, remain totally orthogonal to the nature of objects. There have been attempts to modify Smalltalk-80 in order to unify objects and processes. The main proposals are Actra [Thomas and Lalonde 85] [Lalonde et al. 86] and ConcurrentSmalltalk [Yokote and Tokoro 86] [Yokote and Tokoro 87]. These proposals model multiple activities of objects. A receiver may resume its computation after replying to the caller, allowing the sender and the receiver to resume their respective computations simultaneously. These models remain based on synchronous communication. They will be summarized in section 10 on related work. Meanwhile we may already remark that these models did some change into the Smalltalk-80 model of computation and virtual machine. This quotation from [Yokote and Tokoro 87] explains why ConcurrentSmalltalk evolved from a first version compatible with Smalltalk-80 [Yokote and Tokoro 86] towards a second version in order to alleviate some primitive problems. "Through experience gained from writing programs in ConcurrentSmalltalk, we have become aware of some disadvantages, such as the treatment of: an object shared by more than two processes and the behavior of a block context. These disadvantages originate from the concurrency control that had been designed to maintain compatibility with Smalltalk-80." Our approach is somewhat different because we don't intend to do any change to the Smalltalk- 80 model and virtual machine but we want to propose a minimal extension needed to introduce and study concurrency (i.e. potential parallelism as opposed to physical parallelism) into Smalltalk-80. This approach of studying concurrency models and constructs as an extension of Smalltalk-80 is also advocated by [B'ezivin 88]. But in contrast, our approach is specifically related to our concern with the actor paradigm for Object-Oriented (or Object-Based) Concurrent Programming [OOCP 87]. Smalltalk-80 appears to be a wonderful language to explain and discuss the actor languages, with some impressive economy of tools. This choice of introducing actors into Smalltalk-80 raises the question of their cohabitation with standard Smalltalk-80 objects, and by going further, their complete combination within the current Smalltalk-80 environment and methodology. This issue of combining passive objects with active objects is one of the fundamental issue of OOCP, as pointed out by [B'ezivin 87, page 404]. In order to ensure safety of combination of our actor kernel and Smalltalk-80 we will sketch some methodological rules. It is time now to summarize our goals: 1. preservation, there should be no change made to Smalltalk-80. The system consists in a small extension (a set of classes and methods) to the current image, named Actalk. 2. minimality, this extension should be minimal, in order to be easily understood and ported. All what is non strictly necessary or uneasily implemented has been rejected. 3. extensibility, this minimal kernel will be easily extended in order to model actors able to replace their behaviors as stated in the Actor model of computation [Agha 86], synchronous and eager types of message passing, as proposed by the ABCL/1 model [Yonezawa et al. 87], distributed computation, and further constructs or models. 4. synergy, the current model of objects and the extended set of actors should be compatible and able to cooperate. Some rules are edicted in order to keep a safe mixin. 5. pedagogy, we are personaly involved in the actor family of OOCP languages [OOCP 87]. We intend to use this extension in graduate courses to introduce actor-based programming to usual OOP programmers. Extract: Review of the Smalltalk80 Computation Model Review of the Smalltalk-80 Computation Model Before introducing our model, we will start with a review of the basic principles of the current Smalltalk-80 computation model. 2.1 Sequential and Synchronous Message Passing 2.1.1 Control of Computation The Smalltalk-80 model of computation is based on procedural activation. There is is only one conceptual thread of activity which is passed along objects when messages are sent. The sender of the message transfers the activity to the receiver which will compute the message. (The receiver could in turn send a message to another object.) The sender is waiting for the reply from the receiver and remains blocked until this moment. When the receiver finishes its computation of the message it sends back a value (or by default itself) as the reply to the sender. Then the activity ends in the receiver and resumes back in the sender. In summary only one object is active at a time, and when sending a message the activity is moved to another object before going back to the caller which then resumes its computation. 2.1.2 Environment of Computation This model of activity is very close to procedural or function calls of procedural or functional languages like Lisp. One main difference is that there are no free variables to consider, except the global variables. Only three environments are considered when an object is activated by a message: the environment of the object (made of the bindings of its instance variables, and its class or pool variables which are inherited through its class), the environment of the message (made of the bindings of the parameters of the message) and the global environment (a dictionnary self-referenced through one of its global variable named Smalltalk which contains the bindings of all global variables inside the system). The environment of the sender object is irrelevant and hidden to the receiver. Information exchange between objects should be made explicit through the initial message by passing some arguments, or by explicit messages sent to obtain access to the sender. If we compare with Lisp we note that the environment of an object has to be explicitly and extensionally defined. Objects don't rely on some implicit closure mechanism. Only the global environment could be shared implicitly. 2.1.3 Blocks There is however one exception to this model: blocks. Blocks in Smalltalk-80 are equivalent to Lisp lambdas, i.e. anonymous functions. They introduce delayed evaluation and abstraction into Smalltalk-80. Blocks are mainly used for control structures [Deutsch 81] (note that there is no macro mechanism in Smalltalk-80), and processes. A block (instance of the class BlockContext, or BlockClosure depending on the version) closures the context of its definition. It has already been argued that blocks are not perfectly coherent within the object-oriented philosophy proposed by Smalltalk-80, because objects and blocks have been designed separately [Borning and O'Shea 87] [Ungar and Smith 87] and that they may lead to tricky programming and errors in a concurrent environment. For instance, if an object returns a block as the value of some method invocation, the object is now shared by the block. Thus if the object or the block is shared by a process, this could lead to conflicts as pointed out in [Yokote and Tokoro 87]. 2.2 Multiple Activities 2.2.1 From Blocks to Processes In order to bring multiple activities into the language, processes have been introduced into the Smalltalk-80 system, for instance to run controllers which are waiting for interaction associated to a view on the screen. They could also be created and controlled by the user. The virtual machine schedules the running processes in a pseudo-parallel fashion bringing multiple and simultaneous threads of activities into the language. The problem for the user is the orthogonality between processes and objects. As pointed out in [Yokote and Tokoro 87], this leads to difficulties for the programmer to specify one concept into two different entities: object and process, of different levels of abstraction. The existence of a third concept: block leads to even more complication. 2.2.2 Concurrent Accesses to a Shared Object Because one single object may be shared by several processes, there is a need to protect its internal state from undeterministic effects if there are state changes. This could lead to bugs, known as timing errors, very hard to detect. The relative schedulings of processes accessing to some single data may produce unpredictable results. Smalltalk-80 provides low level tools for synchronization: semaphores. Semaphores allow to control the execution of processes, specially when synchronizing accesses to some shared data. 2.2.3 Synchronization Techniques Most usual problem is to ensure mutual exclusion of processes, i.e. only one of them may execute the critical section where there is some mutation of the object, i.e. change in its data structure. But state changes are specified in the bodies of methods at the object (or rather class) level whereas synchronization should be done at the data level. This dissociation of expressing the changes and synchronizing them makes it difficult to program. Most of the encapsulation gained from OOP is lost. It is not always obvious for the programmer to figure out which data of which object needs to be protected (and which needs not), and to introduce the semaphore signal and wait messages at the right place into the right methods. An example of how to protect a shared object with the use of semaphore objects is presented in a progressive way in [Goldberg and Robson 83, pages 258--263]. The class SharedQueue, which belongs to the standard image, implements a FIFO (First In First Out) data structure whoze size is unbound (except the size of the image!). The queue is protected against timing errors in case of concurrent accesses, and synchronizes the dequeueing requests onto the enqueueing requests if the queue is empty. In this paper, the motivations and the goals which led to design the Actalk system are first discussed. Then the structure and implementation of the kernel of Actalk is detailed. The very good integration of this kernel into the Smalltalk-80 programming language and environment is demonstrated through some examples. Interests and limits of combining objects with actors are then discussed. In the last part of the paper, we demonstrate the expressive power of the Actalk kernel by extending it to simulate the two main actor computation models and programming languages, namely, the Actor model of computation, and the Abcl/1 programming language. Related and further work is summarized before concluding this paper. in ECOOP '89, Cambridge U Press 1989 view details ps in ECOOP '89, Cambridge U Press 1989 view details in ECOOP '89, Cambridge U Press 1989 view details in ECOOP '89, Cambridge U Press 1989 view details in Concurrency: Practice and Experience 2000 v12 view details Resources
|