Objects in Di erent Execution Environments

Objects in Dierent Execution Environments Sven Graupner Technical University of Chemnitz, Germany Faculty of Informatics, Operating Systems Group 09107 Chemnitz E-Mail: [email protected]

June 6, 1997

Abstract

- objects partially expose attributes to other objects by interfaces for interaction, - interacting objects de ne system behavior, - equal objects share equal sets of attributes, - classes describe sets of equal objects, - inheritance relations among classes are used to centralize descriptions of common subsets of object attributes, etc., see also [5, 22]. To summarize, object-orientation provides a method for centralizing and classifying descriptions of models of systems with qualities and relations, that can be mapped into hierarchical structures (class-hierarchies, aggregation). This ideally eliminates redundancy, reduces complexity, and provides a methodology which is close to mental rules for grouping and structuring, and hence for abstraction and thinking. There are also disadvantages of hierarchical structures, but these are not discussed here. Object-orientation basically comprises two domains. First, an analytical for deriving models from parts of reality and describing them in terms of classes, objects, attributes and relations (! OOA). The second domain is constructive: making information processing systems (or parts of them) based on these models. This means stepwise developing elements for an information processing machine, which than can run as the actual application system. During OOD the analyzed model re ecting the application area is transformed into a new model of the processing system to be made. For this model terms of a machine are relevant, such as states, methods, method invocations and others. Although the same terminology is applied, the matter of both models (OOA $ OOD) is

Object-orientation (OO) is primarily a software development technique. One of its major advantages is covering all phases of software development by a widely uniform methodology (analysis, design, and programming). It seems obvious extending this philosophy into running systems, but well thought (object-oriented) software structures are not adequately re ected in processing systems in most cases. Concerning operating systems it is becoming even more sophisticated due to dierent execution environments in dierent system layers. This paper points out reasons for explicit separation of object- (OM) and execution models (EM). A general solution cannot be given. It is intended to describe the problem sphere, to classify domains of executional qualities and to derive a simple model for dealing with objects in dierent execution environments.

1 Object Models and Execution Models

An Object Model (OM) speci es general assumptions of systems which are composed of objects and relations among them. "Systems" actually mean descriptions of models derived from parts of reality, and there is a common methodology, which makes an object-oriented fashion for analyzing (! deriving models) and developing systems (! system construction): - objects are basic (only) components, - objects have attributes: encapsulate states and behavior (! state transitions), 1

’’Models’’

dierent. Designs are subsequently transformed into descriptions (programs { OOP) for conOO Model of an Application Sphere OOA − identifying objects, attributes trolling processing of an abstract machine. It is − object relations − classes, class relations always exposed as a major advantage of objectorientation spawning a uniform methodology General Model of OO Processing OOD and terminology across OOA, OOD, and OOP. − object states − operations, state transitions And for models this succeeds very well. − object interaction (method invocation) Object-oriented programming languages de ne Model of an OO Abstract Machine (like every other programming language) abOOP (defined by an OO−language) stract machines that process programs writ− methods: sequence of instructions − states: association with memory ten in these languages. An abstract machine − processing: carrying out methods combines both, application- or object-related elements from design models (! OM: classes, Abb.1 Dierent Domains of Models in OO class relations, objects, object relations), and Thinking and developing software in terms of elements of processing (! EM: basic process- simpli ed and well structured models and abing elements and means of interaction). stractions eases the software development proThe Execution Model (EM) speci es gen- cess. Insights into realization details are not deeral assumptions of information processing for sired and are not necessary in most cases. a particular real (or abstract) machine or in- However, the abstract machine which is de ned formation processing system with "kinds of el- by a language must be implemented some way. There are two basic principles for that. One ements" and "kinds of processing". is compiling programs for the abstract, objectOM- and EM-related aspects are not clearly oriented machine into programs for a lower separated in most object-oriented languages level, not object-oriented (real) machine and and systems today. OM-related parts can typ- carrying them out by this machine. The other is ically be expressed by languages for specifying running an implementation of the abstract maclasses, objects, interaction and so forth. EM- chine on an underlying machine and carrying related parts are widely invisible. They are im- out programs for that machine immediately. There are several examples for both principles, plicitly assumed by languages or systems. each with its own OM and EM qualities. Some examples can illustrate this for C++. Hierarchies of machines (! layers) have difThere is always only one thread of control in a ferent execution qualities with each layer, and system of C++ objects. Interaction means call- OM-related aspects are usually becoming less ing local procedures as methods. Memory hold- represented down the hierarchy, and execution ing object states is always versatile and not per- dominates the structure. In gure 2 levels of manent. Object identi cation is based on ad- OM and layers of machines with EM are dedresses in main memory. Addresses are unique picted together intersecting at the level of proonly for one processor address space which is gramming an abstract machine (AM). likewise assumed to contain all C++-objects. Method code is xed and cannot be changed Application or extended at run-time. OM : OOA

’’Processing’’

All these are examples for EM-related (implicit) assumptions of C++. Only a small subset(!) of them is de ned by the language speci cation, like storage classes for variables and objects in C++ (static, automatic, and register, see [27]). Others are implementation platformspeci c. But most of them are not visible in programs and actually should not be.

A

OM D :

OOD

OM P :

OOP − AM

Language Abstract Machine

EM p−1

Processing Machine EM p−2 Hardware EM 0

Abb.2 Levels of OM and Layers with EM 2

C++ was discussed above. EM of given languages can only be accepted if these EM are sucient for applications. Sure, this may hold for the class of applications the language was intended and designed for. But there is an increasing number of applications with demands beyond that scopes, and EM must be extended in these cases. "Systems of C++-objects" which spawn across several Unix-processes are examples for that. The EM of C++ alone cannot capture the EMqualities of such a system. There must be a "level behind the C++ world" that encloses Unix-processes { or distributed servers in general { as basic system components. The OM, however, should widely remain unchanged. Another case are multi-threaded extensions to originally single-threaded EM. Again, the OM should widely be unchanged furtherly meeting the original OM-assumptions of a language. The explicit distinction becomes especially important for operating systems with dierent EM in dierent system layers. In most objectoriented approaches in operating systems it is aspired smoothing structuring principles across kernel and application areas to overcome the fraction between both which can be observed today. Object-orientation seems attractive for that. But closing this gap only holds for OM. EM remain dierent in dierent layers. Another reason can be given. Lower-layered machines can become subject of adaptation or development for themselves. This especially concerns adaptable operating systems. Finally, several reasons could be summarized that it can be necessary to deal with dierent execution environments: - distributed applications are beyond the simple EM of many languages or systems, - mapping abstract machines (! languages) to real machines should be adapted, - the application system spawns several layers, - application-oriented adaptations should be supported in underlying machines or layers.

OM-qualities of particular object-oriented programming languages are likewise OM-qualities of abstract machines which are de ned by languages. The "layer-below" machine must however not cover these OM-qualities and usually does not, because this machine is not (or should not be) visible to developers. Hence, OM-qualities are lost during compilation into programs for lower-layered machines without an OM. The other case of running an abstract machine on top of a lower-layered machine is affected as well, that no OM must be applied for the internal structure of the machine itself. Arguments for that are mainly eciency and "no necessity". Higher-level structures lead to more memory- and CPU-consumption which should be avoided, and implementation details should be hidden to developers. To summarize, the mixture of OM and EM in languages results from the intersection of deriving models (OM in OOA, OOD, OOP) with real processing on machines (EM).

2 Relevance of OM and EM ?

The mixture of OM and EM in object-oriented languages is actually not seen as a problem by developers. It seems arti cially pointing it out in such detail. OM-related (! functional) aspects should dominate the software development process. It was outlined above that developing software in terms of well thought abstractions (or models) eases the development process, which should not be overloaded with executional (! non-functional) details of processing without a necessity. A lot of software can be developed in terms of abstract machines without recognizing particular mappings to (or implementations of) "real" executing machines. Mappings are automated, either by compiling or interpretation, and can thus be kept invisible to developers. Software becomes more portable, easier to develop and to maintain. Why should it be necessary to deal with different EM? Today, languages provide more or less comfortable facilities for expressing OM-re- 3 Execution Qualities { EM lated qualities for de ning and deriving classes, creating objects, object interaction etc., but It is quit dicult identifying facets of execution they provide fairly simple EM. The case of qualities. Formalizing them is even more di3

cult and nearly impossible. Therefore, a selec- - relations to addressing spaces of processes: tion is given here which should make the sub- globally shared, ject of discussion more comprehensible. - partially shared, The enumeration can be classi ed into three - individual, major categories of EM-qualities: - access protection for processes: - to objects (permissions),  the existence of objects, - to methods (permissions), - to object states (encapsulation),  the eects of processes, and - to global states,  the global system structure. - means of interaction: The rst domain describes "kinds" of objects, - among processes, - among objects with attached processes. their appearance and their behavior. Objects need some kind of "containers" where they can exist. Qualities of such containers determine  The global system structure comprises basic system elements and relations to objects, the qualities of object's EM. including layers (machines), containers for ob The existence of objects comprises: jects and the allocation of processes: - layers: - installation of objects (type descriptions), - only one with one EM, - creation and destruction of objects, - multiple with multiple EM, ! lifetime (persistent, temporary, volatile), - containers at each layer: - object identi cation, - one global container for all objects, - accessibility (relation to addressing), - multiple containers with one object each, - existence in single or multiple containers - multiple containers with multiple objects, (cached or replicated), relations among processes, containers, object. - xed local place vs. migratable. Objects are primarily considered passive here. Any object { oriented programming language They are subjects of actions which are directed can be classi ed by this (incomplete) list of to objects1, and processes are the actual pro- EM-qualities. It is understood that EM of lancessing entities in a system. Hence, there must guages cannot cover all possible qualities, and be at least on process making a system of they are not intended and designed for that. objects alive. Objects hold and encapsulate2 The EM of C++ was kept simple (! e.g. one states and provide services upon their states single process) avoiding complexity (! e.g. for synchronizing processes). In contrast, Java's for processes (! state transitions). EM comprises a priori multiple threads.  Kinds of processes and their relations to sets of objects have strong in uence on dynamic qualities of EM with following facets: 4 Extending EM or OM ? - (always only) one or multiple processes, Complex systems require more complex EM globally or attached to objects with: than abstract machines of languages usually - one global process among all objects, oer. Hence, EM of given languages must be - multiple global processes among objects, adapted or extended to meet requirements. - one process attached to each object, If the distinction between OM and EM is not - multiple processes attached to an object, explicitly made, OM alone becomes subject of - one process per method invocation, extensions for new qualities. - general process model: Objects should become persistent or should mi- cooperative, concurrent, grate through a system. They optionally should - scheduling policy, exist with multiple replicas or processes should be attached to (active) objects. 1 Active objects are treated as a special case with Many other such features are possible and associated processes. 2 might be useful for particular applications. Encapsulation also gives objects an identity. 4

mantics. The distinction between both is made by implementation technology. New languages require new compilers, whereas extended languages are build around unchanged compilers of original languages. Here, approaches dier by kinds of extension techniques: - source code modi cations by preprocessors, - (class-) libraries with side eects, - link-time modi cations by post-processors, - load-time modi cations, and - run-time modi cations. Source code modi cations and (class-) libraries are most popular techniques. All examples above for "Concurrent C++'s" are using one of this techniques. Presto, for instance, is an example of a class library with a special class Thread. The library also provides means for locks, atomic variables, monitors and so forth, which are necessary for concurrent programming. There are also examples for link- and load-time modi cations to introduce new facilities into languages by resolving method references of compiled modules to wrapper routines with changed behavior (OMOS { [21]). For the C HE OP S -kernel (C++) run-time modi cations are planned for method invocations by manipulating virtual method tables [24]. All this approaches relate to particular languages. Language independent object management systems are faced with the same problem of extending EM. They are even more concerned with the problem, because they are usually intended to be more general, covering various languages and wider ranges of applications. Object management systems, as operating systems supporting object oriented applications, usually provide xed OM re ecting objectoriented issues like objects, object identi cation and naming, interfaces and interaction and others. "Kinds" of these qualities relate to EM, are kept general and thus "heavy" in many systems. BirliX [10] is an example of such a system. Objects (or teams, as called there) are always persistent, distributed (using RPC for interaction) and exist with individual address spaces. Problems are not the qualities for their own, they are certainly appropriate for some kinds of applications. The problem rather is in exibility of the one EM which is provided by

Approaches in languages for extending EM are as old as languages. New languages were designed or derived from existing languages, especially for introducing concurrency [16]. Examples are the "Concurrent"-derivates from languages like C or Pascal [8]. Proposals for new languages were Distributed Processes or CSP [9, 11]. Languages like Ada or Chill contained a priori means for expressing concurrency [25]. All these languages and extensions were developed before object orientation came up. There are several ways for extending EM of given languages which hold for object-oriented languages as well: - designing new languages, - extending languages, and - meta-level languages. Meta-level languages are newer approaches typically in combination with object-orientation. An example is the CLOS extension in [18]. Creating new languages with particular EM qualities for applications has some diculties. A new language with new syntax and semantics must be established for users. Compilers and tools must be developed which is costly and takes time. Only a small number of languages had a real chance to become popular. Users accept new languages only if new qualities come with the language. Object-oriented languages like Emerald, Sather/pSather, Parasol, or SINA [2, 6, 14, 29] are examples for scienti c developments. In contrast, Java is on a good way becoming widely accepted and used. It is more easier extending EM of existing languages than designing new ones. This was extensively done with C++ which is an established language and thus attractive for researchers. And, as it was explained above, C++ provides a fairly simple EM with a lot of directions for possible extensions. Consequently, C++ became subject of many such improvements concerning it's EM qualities. It is understood that concurrency was introduced into C++ with a great variety. Examples are Concurrent C++, C++, Presto, QPC++, ACT++, or C&& [7, 4, 1, 3, 15, 12]. Extended languages provide, as well as new languages, new keywords and new or modi ed se5

els should widely be invariant and not overloaded with changes or extensions holding the line from OOA over OOD to OOP.  A solution is explicitly isolating OM- and EM-related parts in languages and systems.  Meta-level languages and systems ful ll this isolation and separate treatment of OM and EM to a high degree. But the distinction be4.1 Meta-Level Approaches tween "levels" does not always refer to a clear Today's approaches rely more on adaptable distinction between object- and execution or "layers below" (! infrastructures) for achiev- functional- or non-functional qualities. ing higher degrees of exibility, usually mixed with EM and OM of languages or systems. That is also the basic idea of "Meta-Level" 5 "Containers" Providing EM systems or languages: opening up layers "beQualities low" of systems or languages [18, 19]. Using the terminology introduced in the rst sec- If functional- (OM) and non-functional (EM) tion this means nothing else than opening up aspects should be conceptionally distinguished, abstract machines which are de ned by lan- both should be assigned to separate system guages and which are now becoming subject components. This is possible with Meta-level of application-oriented adaptations. This af- systems by concentrating non-functional qualfects realizations and likewise implementations ities in "meta-levels". of these machines, which were hidden to de- Most meta-level systems allow objects controlvelopers in the past [17]. It concerns compil- ling their meta-levels causing eects which are ers transforming programs into lower-level lan- re ected back to objects. It is a matter of inguages and machine implementations as system terpretation what are "meta-levels" in systems. layers. Systems layers can act as infrastructures for suobject-spaces. Infrastructures or system 4.2 Conclusions for Extending EM perior layers are separate and there is a causal conAfter this tour through various ways for ex- nection to "their" objects, that is existence and tending EM in languages, the essentials should processing of superior objects is foremost made possible by an infrastructure or an layer below. be summarized. Thus, infrastructures are "meta-levels", and in EM enclose non-functional qualities. There is not just concurrency as it was exposed above. frastructures can be designed allowing objects There are other domains like persistence, dis- control over their existence, interaction and betribution or replication. There are also dierent havior. An often quoted example for that is the EM between kernel- or user-level objects, and nice-system call in Unix, although Unix is not there are many more of such domains. The va- called a meta-level system. riety of possible EM qualities makes it dicult Meta-level systems explicitly support and endealing with and cannot be captured by one courage meta-level interaction for achieving higher degrees of exibility, especially intended single (and bulky) EM. for extending EM.  Executional demands of applications are becoming more and more manifold and systems In Apertos [30] meta-levels are provided by meta-spaces composed of meta-objects. Obshould support them according to needs. jects are "causally connected" to their meta On the other side, applications require only spaces. This general concept depends on parparticular qualities not all of them. ticular implementations. Other meta-level sys Developers should remain thinking in terms tems, as the CLOS-extension described in [18], of abstractions as far as possible. Object mod- "open up" their implementations, which relates

BirliX. Eorts were taken for "opening up" the BirliX kernel to introduce new or changed EM qualities, as for object interaction by re ective techniques [26]. BirliX was discussed here as an example describing the situation of many general (! universal, "heavy") and hardly adaptable systems.

6

6 Summary

to abstract machines implementing systemlayers. Application objects gain control over machine behavior to a certain degree. It globally aects the machine implementation and is thus globally re ected back to objects and processing in object-space. Individual object- or meta-spaces are not distinguished. Another variant is possible as well and should be proposed in this paper. Not system layers provide a global EM for all objects, but so called "containers" form the environment of existence and processing for enclosed objects. Containers are environments providing certain EM facilities for enclosed objects. Containers can be seen as a special shaping of "metaspaces". However, containers are not made of meta-objects. They are established by infrastructures or lower system layers instead and add a third tier to the coarser grain 2-tier structure of infrastructure and object space. It allows ner and individual EM-tuning according to demands of applications for particular sets of objects and not only globally for all objects. object−level

The model of containers enclosing objects is oriented on observations of real object systems. CORBA and Spring gave primary ideas. The step beyond servers is using containers for comprising individual EM-qualities. Containers can provide dierent EM-qualities for enclosed objects. This allows more exibility by supporting dierent execution environments by adapted containers and is easier to maintain than immediately controlling underlying layers. Objects can widely be isolated from this task by delegating it to enclosing containers. Summarized:

EM 1

intended goals:



practical relevance:



related approaches:

- isolate EM from OM by a further component, - keep OM simple by concentrating EM in containers and than in layers (3-tier), - isolate objects from meta-level control by delegation to containers, - individual EM for subsets of objects are easier to achieve, - ner grained EM become possible. - already applied technique (objects { servers) - simpler implementation technique compared to system layers (! by libraries or RTS).

"containers"

EM



EM 2

- meta-level systems are usually 2-tier, with an meta−level global object-area and one related meta-layer = system layer - meta-spaces of Apertos are rather abstract, = abstract machine containers can be one kind of a meta-space, Abb.3 Meta-levels and Containers - pure servers (CORBA, Spring) are not intenThe idea of containers is based on observations ded for providing various, adaptable EM. in real systems. Objects do not exist in virtual (meta-) spaces. In Unix, they only exist The relevance of the idea of containers is also within Unix-processes. If distributed systems con rmed by newer developments in CORBA. spawn across several processes, the global sys- An example is the Persistence Object Service tem structure cannot only be based on objects, (POS), which is de ned but not yet impleit must also comprise processes (or servers). mented in CORBA systems, like the Orbix system [13]. Persistent objects reside in servers The global system structure of CORBA [20] is that explicitly provide this EM-quality. based on objects (! OM) and servers (! EM) containing objects. There are several mappings Containers with the explicit ability of proof objects into servers. Sun's Spring-kernel also viding individual, easier to application needs supports objects and servers [23, 28] close to adaptable EM are expected to be an advantageous concept for structuring adaptable objectthe CORBA principle. oriented systems. It proposes a direction for The idea of containers is combining servers further research in the C HE OP S -System but with the ability to provide dierent and ner it is still an idea and not implemented yet. grained EM to individual groups of objects. = system layer

7

References

[17] Kiczales, G. Why are Black Boxes so Hard to Reuse? (Towards a New Model of Abstraction in the Engineering of Software). Invited Talk at OOPSLA'94, 1994. [18] Kiczales, G., Rivieres, J. des, and Bobrow, D.G. The Art of the Metaobject Protocol. 335 p. The MIT Press, Cambridge, Massachusetts, USA, 1991. [19] Maes, P. and Nardi, D., editors. Meta-Level Architectures and Re ection, Selected Papers, 355 p., Presented at Workshop Meta-Level Architectures and Re ection, Alghero, Italy, October 27-30 1986. Elsevier Science Publishers B.V. (North-Holland), Amsterdam, The Netherlands. 1988. [20] OMG. The Common Object Request Broker: Architecture and Speci cation, Revision 2.0. published by Object Management Group (OMG), 463 p., Framingham, Massachusetts, USA, July, 1995. [21] Orr, D.B. and Mecklenburg, R.W. OMOS { An Object Server for Program Execution. Proceedings of IWOOOS'92, Paris, France, November, 1992, pages 200{209, 1992. [22] Rumbaugh, J., Blaha, M., Premerlani, W., Eddy, F., and Lorensen, W. Object-Oriented Modeling and Design. 500 p. Prentice-Hall, Inc., Englewood Clis, New Jersey, USA, 1991. [23] Schoniger, F. Spring: Sun's neuer Kern fur objektorientierte, verteilte Anwendungen. Projektarbeit, 27 S., Technische Universitat Chemnitz, Fakultat fur Informatik, Professur Betriebssysteme, Juli 1996. [24] Schubert, F. A re ective Architecture for an adaptable object-oriented Operating Systems based on C++. Presented at ECOOP'97 Workshop ObjectOrientation and Operating Systems, June 10, 1997. [25] Shumate, K. Understanding Concurrency in Ada. McGraw-Hill, London, U.K., 1988. [26] Sonntag, S. Adaptierbarkeit durch Re exion. PhD thesis, 103 S., Technische Universitat Chemnitz, Fakultat fur Informatik und GMD Birlinghoven, Juni 1993. [27] Stroustrup, B. and Ellis, M.A. The Annotated C++ Reference Manual, ANSI Base Document. 447p. Addison-Wesley Publishing Company, Reading, Massachusetts, USA, 1990. [28] SunSoft. A Spring Collection { A Collection of Papers on the Spring Distributed Operating System. Sun Microsystems, Inc., Mountain View, California, USA, September 1994. [29] Tripathi, A., Berge, E., and Aksit, M. An Implementation of the Object-Oriented Concurrent Programming Language SINA. Software-Practice & Experience, 19(3):235{256, March 1989. [30] Yokote, Y. The Apertos Re ective Operating System: The Concept and Its Implementation. Proceedings of OOPSLA'92, pages 414{434, October 1992.

[1] Bershad, B.N., Lazowska, E.D., and Levy, H.M. PRESTO: A System for Object-Oriented Parallel Programming. Software-Practice & Experience, 18(8):713{732, August 1988. [2] Black, A.P., Hutchinson, N.C., Jul, E., Levy, H.M., Raj, R.K., and Tempero, E. Emerald: A GeneralPurpose Programming Language. Software-Practice & Experience, 21(1):91{118, January 1991. [3] Boles, D. Parallel Object-Oriented Programming with QPC++. Structured Programming, 14:158{ 172, 1993. [4] Buhr, P.A., Ditch eld, G., Stroobosscher, R.A., and Younger, B.M. C++: Concurrency in the Object-Oriented Language C++. Software-Practice & Experience, 22(2), February 1992. [5] Coad, P. and Yourdon, E. Object-Oriented Design. Yourdon Press Computing Series, 197 p. Prentice-Hall, Inc., Englewood Clis, New Jersey, USA, 1991. [6] Feldman, J.A., Murer, S., and Lim, C.C. pSather: Layered Extensions to an Object-Oriented Language for Ecient Parallel Computation. Technical report, Technical Report TR-93-028, International Computer Science Institute, Berkeley, California, USA, June 1993. [7] Gehani, N.H. Concurrent C++. Software-Practice & Experience, 18(12), December 1988. [8] Hansen, P.B. The Programming Language Concurrent Pascal. IEEE Transactions on Software Engineering, SE-1:199{207, June 1975. [9] Hansen, P.B. Distributed Processes: A Concurrent Programming Concept. Communications of the ACM, 21(11):934{941, November 1978. [10] Hartig, H., Kuhnhauser, W., Lux, W., and Reck, W. Operating System(s) on Top of Persistent Object Systems. Proceedings of 25th HICSS, pages 790{799, January 1992. [11] Hoare, C.A.R. Communicating Sequential Processes. Communications of the ACM, 21(8):666{ 677, August 1978. [12] Husken, V. Objekt-Orientierung und Parallelitat in Betriebssystem und Programmiersprache. PhD thesis, 137 S., RWTH Aachen, Fakultat fur Elektrotechnik, Februar 1990. [13] IONA. Orbix Reference Guide, Release 2.0. 388 p., IONA Technologies Ltd., Dublin, Ireland, November 1995. [14] Jervis, R. The Parasol Programming Language. Dr. Dobbs Journal, pages 34{41, October 1993. [15] Kafura, D. and Lee, K.H. ACT++: Building a Concurrent C++ with Actors. Journal of ObjectOriented Programming (JOOP), May-June 1990. [16] Karaorman, M. and Bruno, J. Introducing Concurrency to a Sequential Language. Communications of the ACM, 36(9):103{113, September 1993.

8