Communicating active components: An environment for concurrent applications on parallel machines

MIcroprocsssing and Micropmgramming 35 (1992) 47-54. North-Holland 47

COMMUNICATING ACTIVE COMPONENTS:

AN ENVIRONMENT FOR CONCURRENT APPLICATIONS ON PARALLEL MACHINES

Luc COLIRTRAI, Jean-Francois ROOS*, Jean-Marc GEIB, Jean.-Fran~ois MEHAUT

Laboratoire d'lnformatique Fondamentale de Lille - URA 369 CNRS

Universite des Sciences et Technologies de Lille

B~.timent M3 F - 59655 VILLENEUVE D'ASCQ CEDEX (France)

Phone: (+33) 20 43 47 27

Fax: (+33) 20 43 65 66

E-mail: {courtrai roos geib mehaut}@lilLlifl.fr

Abstract. Programming the multicomputers is often a delicate job. This explains our interest in the design and the implementation of an Object-Oriented Parallel Language for a muiticomputero This work is part of the VCP (Virtual Class Processor) project, A fu~; Object-Orianted Environment

for parallel machines is a long-term go~J of this project. This paper presents a unique structuring entity for the multicomputers programming: we call it the Ca¢ (Communicating Active Component). A Cac is an entity which includes an activity which runs a behavioral function, a local context and a mailbox. The behavioral functions and the associated created Cac/s are partitioned in modules which gather the code of application aria the subset of Cac/s. The modules are located on the nodes

of target machine and a module can be duplicated onto many nodes. The module programming and the modules' duplication are two tools of distribution. The distribution of behavioral functions in the modules can be relayed just before the application execution, This can be tuned according to the machine configuration and the network. We will present the implementation realized on the Parsytec Multicluster II, a Tra~;sputer-based multicomputer, under the Helios operating system.

Keywords: Actor, component, concurrency, distributed architecture, mailbox, module,

multicomputer, Object-Oriented Parallel Language, process

Introduction

Concurrency is the subject of much research which covers a very large scope from the design of new computer's architectures to new programming methodolo- gies. Our works are a part of the VCP (Virtual Class Processor) project [3]. The two main studies concern active objects: 1) the expression of the synchroniza-

tion constraints in an Object-Oriented Parallel Lan- guage (OOPL), focused on keeping good inheritance properties [4], 2) the design and the implementation of an OOPL for a multicomputer (non shared memory ar-

chitecture). A full O-O Environment for parallel machines is a long-term goal of this project.

Last years hardware components have made great progress. Now we are able to find very powerful architectures and especially muiticomputers made of many processors [2]. The programming of these machines is often a delicate job for expert programmers. Program- mmg languages, in particular object-oriented languag-

es, remain rare. We think that the object-oriented programming which contributes to the ,,quality software,, production, is a well suited way to facilitate the paralle~ architectures programming.

"This work is supported by ,,R~gion Nord/Pas de Calais,, (n ° 91030068) in a R&D program on Advanced Communication called ,,Ganymede,,

48 L. Coc~raietaL

The notion of active objects allows the integration of a process in the object structure. Each object is then a natural entity of parallelism. Among these active objects, the actors [6,1] are defined by a script which describes the different behaviors of the actor at the time of the message receipt. An actor has got some acquaintances which are the Iocat data of this actor, An actor communicates with others actors by rnes- sage passing. At any moment of its execution, the actor can specify (with the ,,become,, instruction) a new script which will be used for the next message. The model is suitable for concurrent programming. It allows a strueturin~ of application data. Many languages use the actor model. The ABCL/1 language [I3-14]

and Act++ language [7,8] are extensions of actor model on distributed architectures.

In this paper, we present an active structure of low level for the multicomputers programming: we call it

Cac (Communicating Active Component). A Cac is an entity which includes an activity (a thread in the mean-

mg of operating systems), a local context and a mailbox. This structure is realizable above an operating system. The Cac structure is close to actor structure but the programming and the execution model are dif-

ferent. The Cac system is sufficiently flexible for the construction of many models. A concurrent application may be defined as a set of Cacts communicating by message passing. We use the Cac/s for the program-

ming of concurrent applications. In the latter sections, we describe the module notion. The module gathers

a set of Cac behavioral functions, In the application execution, the module is an entity of distribution. It gathers :he part of application code and a set of Cac/s. A module can be duplicated onto many nodes. The

last section presents an implementation of Cao model on distributed architecture. The prototype is realized on the Mu!tieluster l! of Parsytec. We show the main measures of Cac prototype.

1. The Communicating Active Component

We introduced a unique entity for the construction of concurrent applications on distributed architectures. This structure, catled the Communicating Active Component (Cac) stands for the concurrency unit of

an application. A comp';nent is designed by the pro-

grammer who specifies its behavior and [coal data. The Cac run-time supplies a library of "C" functions

for the programmer. This library allows Cae creation and communications behveen Cac/s withnut 2ny ma- nipulation of the low-level mechanisms of the ta~et machine. The "C" language choice gives a good p,jrt- ability of this run-fime on some other target machines and thus a good portability of existing applications.

1.1. The structure of a component

The component structure is close to Agha's actor structure. A communicating active component is made up of three parts: a process (processing part), a mall- box (communicating part) and a local environment (local memory of the component) (figure 1.0).

The process

Each component has an autonomous activity run- ning as an internal process. The code of this process represents the behavior of the component. This ac-

tivity must be designed by the programmer as a "C"

function which will handle the local environment and the communications with the other components. The mailL~×

All the comm Jnications between components use a specialized communication structure. This structure, linked with each component, is a mailbox which stores all the messages for the component, A ¢om- municafion is asynchronous and consists of sending

a message in the mailbox of the recipient compo-

nent. The system takes the message, unblocks the sender, and carries the message to the receiver's mailbox. The message passing is reliable. The component process may extract the messages deposit- ed in its box. A mailbox is created at the component

creation time and its name identifies the component in the system, The local environment

The component local environment is the component local memory. It gathers all the component local data (variables or local functions). This environment is generated dynamically by the component process using two run-fime calls: memory allocation and memory liberation. Only Cac process can have ac- cess to these local data and a protection mechanism of local data is not necessary.

Communicating active components 4-9

Conlrn~lnic~llin~

~ prl)~css

['~ Lnailbox

local CllVlrOllnl~llt

n~tlre ].0 St ructure of CommuniGaUng Active Component The Cac model is independent of the target ma-

chine. But the model must dls*ribute the active entities

(the Cac/s) on the node of the multicomputer. The constraints of Cac system are:

- 1 - A Cac is located on a node of machine. It cannot migrate to an other node.

- 2 - The node must support the structure of Cac. The nodes' operating system must be multi-tasked

so as to receive many Cac/s. The mailbox and the

local environment of Cac are allocated on the

node memory.

1.2. The naming mechanism

The naming mechanism of the Cac model uses two entities:

-1 - The behaviors

The Cac creation requires the naming of a behavior.

The new process of Cac will execute this behavior. A

behavior has a unique global name and may be use in

the Cec creation primitive: Component NewComponent(Behavior B, args...)

This primitive creates a Cac of behavior B. The args arguments are transmitted to the Cac process.

The behaviors are distributed onto the nodes of the

machine, The distribution of the behaviors is handled by the application designer (see laler for the module

notion).

Using the Cac creation primitive, the new Cac is cre-

ated on a node which includes the behavioral -C,, function associated with the behavior.

- 2- The Cac/s

The primitive NewComponentO returns a unique glo-

bal name for the new Cec, This global name allows

commu,~ications to this Cac. The primitive New_Com- ponentO is synchronous and returns the name, in fact the mailbox name of the Cas, identifying the new component in the system.

The communications between components use the

deposit and the withdrawal of messages in the mail- boxes. The messages in a box are stored by order of

their arrivals. Only the owner of the mailbox can ex-

tract messages from this box.

if C is a Cac name, the primitive SendToComponent( Component C, MeesPtr

M) gives the message M (pointer to the message) to the

communication system, which will transmit in the mail-

box of C component. The message must be cre3ted

and prepared before the communication. A p~dicular function allocates the memory space for a new mes-

sage. The message passing is asynchronous. A set of primitives allows the messages from the cur-

rent mailbox to be consulted and extracted. For exam-

pie, the primitive GetMessage(MessPtr *M) extracts a message from the Cac mailbox. If the mailbox is empty, the caller Cac waits for the deposit of a new mas-

sage.

The Cac programming is slightly different to the actor

programming. In actor model, the actor is described by e script which contains a set of behaviors. The Ca¢ programming is lower level than actor model. There is

not the become operation in the Cac instruction. The

behavioral function of Cac can implement the actor

script. But the execution model of Cec must be explic-

itly described.

1 .3 . E x a m p l e

To illustrate the Cas model, we will now present an

example of behavioral function for a binary search tree node Cac. The binary search tree is a data structure storing a key set. The tree is sealed by the nodes' val-

ues [14].

The operations on the tree are:

- 1-storeavalueinthetree.Theinsedionsearches for a leaf from the root of the tree. It then changes the node value through the inside message key and creates two voidsub-nodas.

- 2 - search a value in the tree. The search starts

from the root of the tree, which then sends the

look-up request down the tree. If the value is not found, a special voidvalue will be returned.

In our impiementation, the tree can process concurrent requests; but a node is blocked during the rues-

50 L. Courtrai et aL

sage treatment in the node. Each tree node is

implemented by a Cac. The process of Cac initializes

the local data and waits for the first message. When a

message is received, the node extracts the request

name of the message and executes a part of the code.

In the example, we use two functions in order to fa-

cilitate writing and reading data in messages. "i he

ConstructMess(MessPtr *M, data V) function builds a

message Mwhich contains one data V. A datatype is

a primitive type or a Cac reference (Component}. The

data ReadArg/MessPtr m) function reads the next ar-

gument of the message m.

The example shows the definition of the behavior

called node. This behavior is used to create the active

nodes (Coo/s) of the binary search tree.

/" Behavior of 1roe node "/

Behavior(node) { MessPtr rues, reply; Component left. right, sender; int value, rnes_value; left = VOID; right = VOID; value = VOID; loop (

GetMessage(&rnes); /" resquest name */ switch (ReadArg(mes)){

case STORE: /" insertion *l rues_value = ReadArg(rnes); I" value to store '/ if (value == VOID) { /" leaf "/

value = mes_value; left = NewComponent(r~ode); right- NewCornponentlnode};

}else if Ivalue > rues _value) SendToComponent (left,rnes);

else SendToCornponent(right,rnes);

break; case SEARCH: I* searching "/ rues_value = ReadArg(mes); I" value'[o search "1 sender = ReadArg(rnes); /' request sender "/ if (value == VOID) { /* lear'/

ConstructMess(&reply,FALSE); SendToCom ponent(sender, reply);

} else if (value == rues_value) { COrlstructMess{&reply, TRUE): SendToCorn ponent(sender.reply);

} else if (value > rnes value) SendToCom ponent(letl,mes};

else SendToCom ponent(rk:jht,m as);

break; }

eodleop }

figure !.1 The beharioral functlen of tree nede

The STORE and SEARCHING words are defined in

a header fi~e which may be included in others behav-

iors, clients of the described behavior.

2. The modules

2.1. The module definition

The behaviors must be distributed on the machine

nodes. We introduced a logic entity for the distribution

of Cac behavioral functions. An application code is

then partitioned in modules. The distribution of be-

havioral functions in the modules can be relayed just

before the application execution. It can be easily mod-

ified without Cac source modification.

A module contains a subset of the behaviors used in

an application. The module is a distribution entity of

Cao/s on the machine nodes too. In the application ex-

ecution, it gathers the created Cac/s using the en-

closed behaviors. The Cac/s ere then distributed

following their membership of modules. A Cac is cre-

ated and is located in a module that contains the con-

cerned behavioral function of Cec. A component

evolves in a module and remains throughout its life on

the machine node where the module is located,

Each module is also an active entity which has its

own specific activity. This activity manages the cre-

ations and the destructions of components in the mod-

ule. This <,module manager,, is implemented by a

specific Cac which receives some ,,module requests~

in particular the component creation requests in this module.

~ Module

~ ~a n°dcei°fn ~ bchavi°ral

(~Cac "~'id] the b~havior bl ~ module manager

RI~ Cac crealion

figure 1,2 Tile Cads and the module mmtager

Modules primitives

The distribution of behavioral functions in the mad-

uies must be described by the application program-

mer. If a module contains one and only one behavioral

function, the module notion is close to Coo ,,class,,.

But the module notion is different to Cac class. The

module notion is more flexible than the class notion: a

Communicating active components 51

module can contain many Cac behaviors and several modules can include the same Cac behavior.

The module code is de:scribed by a -C- file. The name of this ,,C,, file designs the logic name of module. The file tells what behaviors will be handled by the module.

The primitive InsertBehavior(Behavior B) adds a new behavioral function in the module. This function is an instruction of the main function of module (initializa- tion part of module). This means that during the application execution, this module might contain Cac/s of this B behavior. Example

We show the module code which contains the Cac

behavior of the tree node. The ma~O function initializes the modules.

~xtern Bah a v,o r IMnNOelD; E "/

int n}ain 0

) nsertBehaviorlnodel;

fig|Ire 13 The code of Node module

In this example, the node module is similar to a class of tree node, i.e. the entity which can create instances of node.

2.2. The modules on the maohine nodes

After the compilation of the application modules, the

programmer describes a modules' network. Each module is put up on a node of the target machine. A machine node can received many modules. The programmer himself may distribute the modules on the nodes. But he may also leave this task to the system. The modules' distribution is then conditional upon the loading of machine nodes.

The execution environment proposes an additional tool for distribution.The system allows the modules' duplications: a module can be duplicated onto many nodes. The programmer describes Cac modules and before the loading of the application defines a duplicated modules' network.

The next figure shows an application with 2 modules. Each of them are duplicated.

Node N0¢¢_4

§guR I A The ~wdu/es und du,~/cated m~'u ~ s on l ~ ,tod~

The duplication ac~antages are: - f - to unload the memory of machine nodes. A

module is duplicated on different nodes. The system automatically balances the component cre- ations on the duplicated modules. The node memory is uniformly allocated.

- 2 - to increase the application parallelism. Without

the module duplication, the CacJs of same behavior are located on one module. There is not a real parallelism of execution between the Cac/s. With the module duplication, the model allows a real parallelism between the CacJs of duplicated module.

The component distribution in the duplicated modules is based on a cooperation between the different module managers: the component of behavior B is created in the less loaded node containing a module

with the behavioral function B. The distribution a~go- rithm can be raprogrammed by the application desert- er.

This duplication phase is independent of the modules' programming. It is an execution parameter. The programmer can adapt the application execution of his application to the target machine without source modification.

The InsertBehaviorO primitive (in the module pro--

gramming) and the module duplication (in the network construction) are two tools of distribution of cede and Cac/s on the machine nodes. Without the duplication of modules and with one behavioral function in each module, the class notion is the tool of distdbution~ On the contrary, it all behavioral functions are in one module duplicated on all nodes of the targat machine,


Cac/s can be created on any nodes. Any intermediate solution of distribution can be used for specific fine-tur- ing.

3. implementation on the Helios system and measures

A prototype of the Communicating Active Compo-

'~ent runqime is implemented on a multicomputer: the

MLdticluster If [9] by Parsytec. Each node consists o, ~ a

T8O0 Transputer (25 MHZ, 10 MIPS) and 2 Mbytes of local memory. It communicates with its neighbours by four links through a 20 Mbits/s transfer rate. The, ma-

chine is totally reconfigurable.

3.1. The Helios system

We choose the Helios operating system available on the Multicluster II for the following reasons: it allows the C programming, manages the message routing

between the nodes and suggests a mapping tool.

Helios [10] is a distributed UNIX-like operating system [11]. It allows the underlying machine concurrency

to be used and also its communication possibilities

too. We used the C-ANSI compiler of the Helios sys-

tem. Let us detail the tools of Helios for concurrency and communication.

Concurrency axpression in the Helios system: The task notion of Helios is near to this of the UNIX

process. An Helios task is attached to a certain num-

ber of system resources. An Helios task includes code

(functions including a main function) and data (a stack and local data).

A concurrent Helios application consists of a set of

tasks. These tasks execute in concurrency (or pseu-

do-concurrency) on the different nodes. The CDL

(Component Distribution Language) allows the distribution of tasks to be expressed. An Helios task is cre-

ated On a Transputer and cannot ,,migrate,, during its execution_ The programmer can leave the choice of

the best location of the tasks to the CDL and this ac-

cording to the Transputers' charges at the program starting time. The programer can force a task execu-

tion on a given Transputer. in order to minimize the communicating costs.

The Tran~puter uses micro-ceding to implement a

lightweight process scheduler. Each lightweight process owns an evaluation stack of procedural calls (at

minus 1Kbytes). The processes, that are created in a

task, share the memory space of the task. These processes are lightweight because they do not need any

important memory resources and are scheduled by the hardware.

Communication expression of Helios system:

The CDL allows the distribution of the tasks on the machine nodes and also allows the oommunication links between tasks to be set up. The low level com-

munication of the Helios system, communication by

,,Ports,, is not reliable, So, we choose the Unix pipes

communication. The UNIX primitive write (ie read) is used to send (ie receive) data to another task.

The task processes can communicate through the

task memory. Semaphores must be used to protect the data and to certify the integrity. The processes use

the pipes to communicate with other task's processes.

A study [5] evaluated the Helios system. In the figure 1.5, we look at again the main results of this evalua-

tion, Some measures were reevaluated in best condi- tions.

IFunetion.s T i m e (~)

variable ass ignemenl 0,6

C ftlnction Cal l 2.7

mct l lo ly a lkn:at ion 164 - 1024b] 70.0 - 70.0

m e m o r y l ib6rat ion 164 - 1024bt 7 0 . 0 - 70.0

process creat ion IS0.0

m e m c p y ( 6 4 - 1024b) 9 ,0 - 67 .0

communica t ion by pipe(64 - 1024b) 1080.0 - 1850,0

fignre I,.~ ltelios measures, time in micro.seconds

The study shows that the memory allocation and the process creation are expensive on the Helios system

compared to the procedure call, The communication

layer by Helios pipes is reliable, but the performances

regarding the communication by ,,Ports, are miner.

3.2. The prototype

The Cac prototype uses the Helios system's main functionalities: memory allocation, process creation

Communicating ac~ve componenl.~

and communication by pipes. A communication layer

on the pipes implements the boxes. The box creation

returns a global name which is constructed from the

site name and a local name of box on the task. A box is composed of: a linked-list of unused messages, e

semaphore for the waiting of Cac process when the box is empty. A local communication is a memory ac-

cess in the shared memory and a remote communication uses the UNiX pipes.

The modules are implemented by Helios tasks. It contains the executable code of the behavioral functions of module and the Cac run-time (creation func-

tion, communication primitives...). A table stores for

each behavior a list of the module whe, e this behavior

is implanted. The modules' network is described by CDL program which is generated by a system tool. The programmer can modify this CDL program sc as

to force the system to implant a module on a machine

wanted node. A machine node can received many

modules. These modules' code is then merged in one

physical module. During the initia!ization phase, the modules notify each other of their names and their list of the behavioral function names.

A Cac activity is a process created in the task asso-

ciated to the module. The mailbox is allocated in the

module where the component is created. The mailbox name designs the component. The local data are allo-

cated in the node memory. The communications be-

tween Cae/s use the boxes' communication.

The Cac distribution uses the following information: the loading of nodes (number of Cac/s on the modules of this node), the tocalisation of the behaviors.

The figure 1.6 gives the main measures.

Primitives Time (ms)

NcwComl)o.Bcnt (local - rCmolc) 0.280 - 3.750

5cndToCollq}oBuat --- l~cal (64 -1024b) 0.210 - 0.210

ScndToConlponcnt --- Icmote (64 -]024b) 3.460 - 4.250

Gcl_nlcssagc (the mailbox is uot Clllply) 0.245

figlgre 1.6 Run.time mca~gtcres, tlme In mlllr.seconds

AS in the previous measures, the prototype primitives are penalized by the Helios memory man~ge- ment.

53

3.3. Application measures

We measured the execution time of the binary

search tree. Each Module contains only one behavior-

al function. We measured the performances of mod-

ules' duplication. We executed 500 insertions and 500 searches for random keys in the tree. There are 10 Transputers. The network is constructed so as to limit

to 2 the number of intermediate transputers for each

message passing. (The machine node communicates with its neighbours by four physical links)

t imes in (s)

20¢

50

number td" Rode ~ dules

f igure 1.7 Measures of application execution

With one transputer, the measure corresponds to the pseudo-parallel execution.

The results are made up of two oases:

- 1 - There a;e less modules than transputers. The

result with n modules is close to the application time on one module which is divided by the num-

ber of duplicated modules n. The best results are obtained when each node has" got one and only one module.

2 - There are more modules than transputers.

Some duplicated modules are impTanted on the

same node and several module managers are created on the same node. The cooperation between

the module manager creates a communication

overhead which is not compensated for by the machine parallelism.

The results show the benefit performances of the modules' duplic~tian arid they show too the interest of

constructing the modules' network, independent of the modules' programming.


Conclusion

Parallel machines need specific tools to manage

their complexity. We have introduced the Communi-

cating Active Component as an abstraction of the concurrency unit for these mach!qes. A Cac groups an activity, a mailbox and local environment together. The

Cac/s are themselves grouped together in modules. A

module contains the code for the Cac/s it contains. A

modu!e is an active entity which processes the cre- atior'Jdestruction of Cac/s and processes the load bal-

ancing between duplicated modules. The module duplication is a tool of code distribution on the machine nodes. The programmer can adapt the applica-

tion execut ion for the target machine.

The Cac model is independent of low-level mecha-

nisms of the target machine. For example it hides local and remote communications behind a unique primi-

tive. The distribution of components uses CDL pro-

grams that are not part of the components code. The

model exhibits a fine-grained concurrency that allows programmers to take the best of the high potential per- ;ormances of parallel machines.

The current implementation used the Helios system

and so inherits limited performances of this system.

Other implementations are under work. The current

work deais with new implementations of component run-time on other architectures. A version is being de-

veloped on a network of ~UN workstations by using the lightweight processes [12].

We are now working on a distributed garbage collector. The idea is as follows: on each module, a local

garbage collector processes all the non referenced

components out of the module. The other components

are managed by a distributed garbage collector using

the communication network, When the process of a

component finishes, the component is automatically reclaimed by the Ioca~ garbage collector.

A large scope of applications are concerned by the Cac model: parallel applications and especially concurrent languages.

Our first experiences with our prototype show that is interesting to exploit mutticomputers, to write concurrent applications and to use real parallelism in compu-

tation. A full Parallel Object-Oriented Programming

Language, based on Cac/s, is being studied. The problems related to synchronization (which are not ap-

proached is this paper) are a great challenge in this

part of this project. We ,'~re investigating the use of

speciarized Cac/s to deal with these problems.

References

[I] G. Agha Actors, A Madel of Concurrent Computation in Distributed Systems, The MJT Press, 144 pages, 1986

[2] W.C. Athas, C,L. Seitz Multicomputers: Message- Passing Concurrent Computers, IEEE Computer. 21t8), pp 9*24, August 1988

,r3] L. Courtrai, E. Delattre, J,M. Geib A Server Based Architecture to Support Object-Odected Languages on Mullioomputers, internal report ERA 95, University of Lille 1 (F), April 1991

[4] L. Courtrai, J.M. Geib, J.F. Mehaut Inheritance of Syncl?rontzatien Constraints in the VCP system, in EastEurOOPe'91 Proceedings, pp. 57-90, September 1991

[5] F. Hemery, D. Lazure, E. Delattre, J,F. Mehaut An A, lalysis of Communication and Muitiprogrammieg in the helios Operating System, Euromlcro, pp, 137-147, September 1991

{6] C. Hawitt Viewing control structures as patterns of passing messages, Journal Of Artiticlal Intelligence, pp. 323-364, 8-3, June 1977

(TJ D,G. Kafura, K.H. Lee Inheritance in Actor Based Concurrent O~ect-Oriected Languages, The Computer Journal, Vol. 32, NO. 4,1989, pp. 297-304

18] D.G-Kaiera, K.H, LeeACT+~:BuitdingaConcurrerffC++ with Actors, in JOOP J0uratd of Object-Oriented Programming, pp. 25-37, May/June 1990

[9] Peraytec G m b H Multicluater-2. Technical Decumentation, Installation, expansion and mairrt~cence manual Ray. 1.1, May 1990, Juelicher straSe 338, 0- 5100 Aachen

[10] Perihelion Software The HELLOS Operating System. Prentice-H.3il, 1989

[11] D.M, Ritchie, K. Thompson The UNIX Timc-Sharieg System, Communications of the ACM, Volume 17.1974

[12] Sun Microsystems System Services Overview. Chapter 6: Lightweight Processes, 1988, Part Number 800-1753- 10

[13) A. Yonezawa, J. P. Briot, E. Shibayama Object-Oriented Concurrent Programming in ABCL/r,ooPSLA'88 Pro¢. of the ACM Conf. on Object-Oriented Programming Systems. Languages, and Applications, Portland. Oregon, October 1986, Special Issue of SIGPLAN Notices, VOl. 21, NO, 11,1986. pp. 258-268

[14] A. Yonezawa ABCL, An Object-Oriented Concurrent System, The MIT Press, 1993

Documents

Communicating active components: An environment for concurrent applications on parallel machines