Parallel and Distributed Programming with an Actor-Based language"

J. HernBndez*, P. de Mipel", M. Barrens*, J. Martinez*, A. Polo*,M. Nieto".

* Computer Science Department. Extremadura University. Spain.E-mail: qua@@ fi.upm.es. 4 Architecture and Technology of Information Systems Department. Technical University of

Madrid.Spain. E-mail:mnieto@fi.upm.es.

Abstract ALBA, A parallel Language Based on Actors is a new

programming language designed to take advantage of highly parallel architectures that use message passing as the fundamental low-level interaction primitive.

In this paper, we present the contribution of ALBA to develop parallel and distributed programs through well known parallel programming paradigms. We discuss how process groups and group communications are modeled in our language using meta-actors, and by extrapolation, in other actor-based and object-based concurrent languages. In addition, we describe a new programming paradigm called the Actor-Tuplespace, which integrates the Actor and the Linda models. The Actor-Tuplespace allows a simple way of specification of synchronization constraints among actors. Tuples do not contain values as in the Linda model, instead they contain messages and other attributes described in this paper. The use of the Actor-Tuplespace is applied to the definition of distributed data structures.

1: Introduction

The key concept of object-oriented programming languages and systems is the notion of object. An object encapsulates data, representing its local state, and contains a collection of operations manipulating that state. In a system composed of objects, objects send messages to each other to perform computation. An object cannot affect the state of any other object in the system. The only possibility that an object may get or change the state of another object is by sending a message to the target object. The received messages activate portions of code, commonly called methods.

Object-based sequential languages allow one object to be active at time. The potential of massively parallel

V This work has been partially developed under the Parallel Computing Action of ESPRIT project nQ PCA-4002 and the TIC93- 0701-C02-02 project.

architectures is then lost, because the sequence of actions inside a method of the object become blocked when a method in another object is invoked. This situation contrast with the parallel nature of the universe, when the programmer wants to model a real-world situation in which objects interact among them in an actual parallel way.

Because of the idea of autonomy and independence of an object, many people have considered OOP as a good basis for modeling concurrency. Objects fit well with concurrency since their logical autonomy makes them a natural unit for concurrent execution. Object-based concurrency allows concurrency of real-world applications to be naturally modelled [ 131.

Due to these reasons, object-oriented concurrent programming languages and models is today one of the primary goals of researches and different companies who develop ambitious applications in a wide number of areas El.

The long-term goal of our research group is the development of a parallel database machine, called QUATRO [4] that tries to exploit the characteristics of multiprocessor machines for quick processing of users transactions.

In order to allow a modular and structured design of QUATRO, we needed a suitable programming model for making easy the building of a large and complex system by hiding specific machine details which sidetrack our mind. ALBA was born as a result of the establishment of this requirement for a programming model. Rationales of the design of ALBA can be found in [9].

The goal of ALBA is to provide a platform for experimenting with concurrent computation on generic parallel architectures consisting of a set of processing nodes with no-shared memory which are able to communicate among themselves by means of a high-speed interconnection network, such as a Transputer network.

In this paper, we present the contribution of ALBA, for developing parallel and distributed programs. Moreover, we show how both traditional and even the most recent

0-8186-5370-1/94 $3.00 0 1994 IEEE 430

parallel programming paradigms are easily developed in ALBA. In addition to that, we present a new programming paradigm called Actor-TupleSpace, which integrates the actor [ 11 and the Linda models [ :5 ] .

The paper is organized as follows. Section 2 discusses the change of behaviour of actors, a key concept for well understanding any actor systern, and we show the main differences between ALBA anti the Agha’s actor model. Significant differences with others object-oriented concurrent programming languages can be found in [8]. Section 3 reviews different paradlel computing paradigms, from the classical to the most recent ones. Section 4 describes the ability of prograniming in ALBA, focusing in the solution of problems that use the divide and conquer programming scheme and the process group model. In section 5 we present briefly the Actor-Tuplespace paradigm, and paper ends with cur conclusions.

2: The Actor Model

The actor model has been proposed as a programming model suitable for massively parallel architectures due to the high degree of parallelism inherent to actors. The processing of a single communication for an actor may result on the execution of k+ntl parallel activities, as a result of both sending k new messages to other actors and creating n new actors.

The actor model unifies objects and concurrency. Actors are active computational agents which react in response to incoming communications [l]. Due to the fact that the behaviour of an actor can be affected only by sending it a message, actor-biased languages maintain privacy and security of the internal structure in an individual actor.

Traditionally, actor-based languages are classless languages, and the behaviour of an actor is expressed as a function of the incoming communication. The become primitive (the replacement behaviour mechanism) gives actors a history-sensitive behaviour necessary for changing the data state. It also allows an ;actor to change its script at run time.

The replacement behaviolur (i.e., become a new behaviour) is, perhaps, the key concept for a well understanding of any actor system, which is explained in the following subsection.

2.1: The change of behaviour of actors

Replacement differs from a c:hange of local state. There is no concept of variables or assignments in the actor model.

In a system allowing local state change, there is an update of the variables of the: old state. In the Agha‘s

model, when an actor needs to change its local state, it performs its replacement behaviour. That is to say, the actor becomes in a new actor with its local state (its acquaintances) changed to the new one. This allows the new actor to accept the: next communication and thus, both the previous (containing the previous state) and the new one (containing the updated state) can run in parallel. This is, perhaps, the moat powerful feature of the genuine actor model.

However, this situation may lead to an inconsistent treatment of data, if the replacement behaviour is carried out in an unproperly manner. Once the operation of an actor in response to a particular communication has been determined, then and only then, the actor may change its behaviour (i.e. become a new behaviour).

The ability to specify a replacement behaviour retains an important advantage: over conventional assignment statements. It allows pipelining at statement level, and thus, concurrency at statement level. For example, and following a classical case reported in many works about actors, suppose a bank account actor which accepts a withdrawal request. In response to that, as soon as the actor has computed the new balance in the account, it may specify its replacement behaviour with the new balance, even if other actions implied by the withdrawal request are still being carried out. This replacement allows potentially numerous threads to run through an actor.

We began the previous paragraph with the keyword “ability”. Although the potential parallelism provided by the replacement behaviour is very high, it is also very high the potential errors derived from the fact that two different threads of an actor may be running with distinct values of their states. Following with the previous example, the statements that follow the replacement behaviour cannot use any more the balance of the account, because it has been changed, and the new balance is now an acquaintance of the new actor machine Xn+l and it is unavailable for the actor machine Xn’. The replacement behaviour is thus both a powerful and dangerous mechanism.

In effect, this change of behaviour involves creating a new actor with the same mail-address that the previous actor. The actor representing the replacement behaviour has as acquaintances the new state of the actor. The script of the new actor may be either the same as the previous

We have followed the notation used by Agha in [lo], where an abstract representation of transition of actors is described through actor machines Xn which is responsible for processing the n%ommunications sent to <an actor. When an actor machine Xn

X n + l as a result of its replacement behaviour. There is no interference between them.

accepts the n h communication, it will create a new actor machine

421

actor or a new one. In this way, an actor may change its script at run time.

The reader may wonder about the effectiveness and efficiency of the actor model because the necessity existing for creating a wide number of actors for doing a (single) computation and, in consequence, the overload of the processors (in the Agha’s model, a new actor is created whenever a replacement behaviour is taking place, and in particular, always that an actor change its state). But as Agha remarks in [l], different implementations of the actor model may decide about the necessity of creating a new actor machine in response to each accepted communication.

In order to avoid both the potentially inconsistent treatment of data (excessively dangerous in a database system) and the overload of processors, actors in ALBA use conventional assignment statements for change its state. In ALBA, the become primitive is only allowed when an actor changes its script as a result of an incoming communication.

2.2: Actors in ALBA

The environment of an ALBA actor system consists of an extensible set of actors that are organized via a class- based object model, where each class is defined as follows

DEFINE ACTOR name [ON( cluster-id I host-id }] [unserialized] :

LOCALS

local actions, if they exist INTERFACE

Messages to be received. m

Actor initialization actions. ACTIONS

WHEN label1 * action1 /* HELIOS-C and

variables (C variables and actors -included itself-) and

ALBA statements */ .... WHEN label, + action, OTHERWISE action

END ACTOR name.

Actors are created dynamically with the CreateActor primitive

CreateActor(name) [ON {cluster-id / host-id / H E M } ] allowing (if it is desired) the programmer to select at run time the processor or network of processors where actors will be allocated.

An actor is identified by its mail-address (associated with its name) which is generated when the actor is created.

The mail-address of an actor may be freely communicated among actors of a system and thus, it allows the system to be both reconfigured and extended.

As actors are independent active entities, parallelism is modeled simply by creating actors. We can distinguish between two different levels of parallelism: medium-grain parallelism among actors (i.e. serial execution of methods inside a serialized actor) and fine-grain parallelism inside actors (i.e. parallel execution of methods inside an unserialized actor).

Communication in the Agha’s actor model is asynchronous point-to-point.

In ALBA, primarily message passing among actors is also asynchronous, allowing the sender to continue after sending a message.

Moreover, ALBA achieves synchronization by means of a traditional remote procedure call which is not supported in the genuine actor model. Once sender and receiver are synchronized both can be running in parallel.

The ALBA waitfor statement allows the sender of an asynchronous message to wait at a time later for a specific reply or a reply coming from an specific actor to which a message was sent a time later. A such similar facility is that of the use of futures [13]. Instead of waiting an actor A for an expression to be evaluated, the expression may be sent to an actor C able to solve that expression in order to evaluate it concurrently with other code of the actor A. Whenever the value of the expression is needed, the actor A will wait for it (if C still has not evaluated it) or proceed with the required value. Futures is a mechanism by which computation can proceed in parallel with the requirements of the expressions that may be needed a time later in the computation. In addition to that, the ALBA waitfor primitive allows a more efficient change of behaviour (at script level) as it is explained in [lo].

The multicasting mechanism in ALBA has as its starting point the original idea of BSP [7] but overcomes the lack of knowledge concerning the process names involved in a communication. This lack is also found in some actor-based languages that have tried to implement a broadcast mechanism such as PLASMA-I1 [ll]. ALBA achieves multicasting by method invocation at the class level. All instances of the class corresponding to the current application will be the target of the message, independently of the number of actor instances, its names, location, etc.

3: Parallel computing paradigms.

Different programming paradigms have been developed in order to facilitate the not easy task of building parallel Software.

422

In this section, we discuss some of the most important of those paradigms and we show how some of them are developed in our language, andl by extrapolation, in other actor-based or object-based concurrent languages. Pipeline concurrency. When a task is broken into smaller components and the results of them are sent one after another through consecutive stages of processing in such a way that several components are working simultaneously, we speak of pipeline concurrency. This is modeled in ALBA by a sequence of Al, ..., An of actors. Each actor Ai in principle only needs to send messages to its successor in the pipeline Ai+l. Because we want the objects to execute independent of each other in time, asynchronous communication should be used The most natural way of creating a pipe-line is by letting an actor Ai create its successor Ai+l. There are as many actors participating in the pipe-line as they needed. This is achieved due to the fact that ALBA allows an actor to be defined in terms of itself. In addition, the proper result obtained at the end of the pipeline may be sent to the actor which originated the pipeline if its mail address is propagated through the pipeline. It is made in ALBA using the @reply pseudo-variable. Master-worker paradigm. If the processing of a task is decomposed into a number OF identical subtasks each of which performs the same action with distinct pieces of information, we say that the problem is solved using a master-worker programming scheme. The master-worker programming scheme involves three main steps: firstly, splitting the task into subtasks, creating processes (workers) for the execution of the subtasks and sending the piece of the problem to each worker; next, parallel execution of workers; and, finally, sending the results of the workers to the master process to create the final result. The master-worker paradigm needs a coordinating actor, say M. If n is the number of subtasks, the master creates workers W1, ..., Wn for carryimg out the subtasks. After creation, each worker gets its piece of problem to be solved via an asynchronous method from M. Upon completion of its tasks, each worker sends its results to the master. Because ALBA alllows the definition of data structures composed by actors we can define, for example, a fixed number of workers (array of workers) or a dynamic data structure composed by iictors, etc.. They will be created by the master, and therefore, all the descendant workers know the name of its creator stored in the @creator pseudo-variable, makiig so possible each worker to send its result to the master. The master may wait for the collection of all the results with the waitfor primitive.

A slight variation of this paradigm is the bug-of-tusk approach, primarily presented in Linda-like languages [5 ] which shown how to parallelkee any divide-and-conquer algorithm, subject only to the requirements that

subproblems be independent. The solution of this kind of problems uses a shared bag of subproblems. Initially, there is one task on the bag corresponding to the entire problem to be solved. Multiple worker processes take tasks from the bag and pirocess them, often generating new subproblems that are put into the bag. The computation terminates when all tasks have been processed. This approach is carried out by means of a shared actor representing the bag, with the appropriate data structures for storing data corresponding to the subproblems to be solved. Put and get methods are used for putting into and getting from values in the bag, respectively. These values correspond to the actual parameters of the different subtasks to be solved. Workers know the bag they must interact as a result of a received (init) message including the proper bag mail-adhss. Clientlserver model.. When a process repeatedly handles requests from other processes we speak of clienvserver computing paradigm. Clients and servers are naturally modeled in ALBA. Any actor waiting for requests (messages) may be identified as a server. Clients can interact with servers if they know the server mail address. Clients and servers can be located in any node of the network and usually they are at distinct places. Receiving a server mail address as parameter of a method is the most usual way for a client to be aware of a server name. Divide and conquer concurrency is carried out by the concurrent elaboration of different subproblems (usually performing the same action but with distinct pieces of data) and the .joining of their solutions in order to obtain the solution of the whole problem. In this scheme of parallelism, there is no interaction among the entities responsible for solving the subproblems. There is no master coordinating tlhese entities and there is no shared bag-of-tasks. The use of this paradigm in ALBA is detailed in the next section. In an upper level, we have the Cooperative problem- solving [2] where a collection of autonomous objects communicate among themselves (cooperate) in order to obtain a solution of the original problem. Intermediate results are stored in objects and shared by message passing among objects. An exarnple of this approach is a database machine, where differenlt objects cooperate to manage the database. Ones in charge of processing the requests that users issue; others by performing retrieval tasks, etc. Probably, some of the ctbjects that cooperate to solve the whole problem use one of the above paradigms. Process groups [12], where objects are grouped to provide a service. Users view each group as a single entity, which usually has common characteristics. For example, some printer servers may be grouped in a single entity. Clients send requests to the group which,

123

internally, provide the service. Actor groups in ALBA are detailed in section four.

Based on the process group concept, recent progress in actors have developed the new ActorSpace computing paradigm [3]. An ActorSpace is a computationally passive container of actors which acts as a context for matching patterns. Pattern matching is used to pick actors whose attributes satisfy a given pattern. Clients of an ActorSpace send messages to one (selected in an undeterministically way) or all members of the group. Associated with each Actorspace, there is a manager which provides security (using capabilities) and coordination of the messages sent to the group.

We have designed another programming paradigm called the Actor-TupZeSpace, which integrates the Actor model and the Linda model, which is explained in section five.

4: Parallel and distributed programming with ALBA

It has become traditional in papers describing actor system to discuss the implementation of a recursive factorial as an example. Mainly, it is because of the fact that by means of a such simple example, it is possible to describe the power of actor systems, and thus, not to sidetrack the mind of the reader with the problem per se, focusing so in the different ways that problems may be solved in parallel with actor systems.

In this section, we present different solutions to the factorial problem using the divide and conquer and the process group computing paradigms. Problems solved in ALBA with the first three schemes can be found in [9].

4.1: Divide and Conquer strategy.

In sequential languages, a method solved in a recursive way, such as a factorial function, is implemented using a stack of activations. However, there is no mechanism in such languages for carrying out the method in a parallel way and for processing more than one method (several factorial computations) in parallel.

The creation of customers (also called join continuations in [2]) is the technique usually followed in actor languages for processing more than one method in parallel relying in the fact that customers provides a mechanism for maintaining partial results, as stacks do in sequential languages.

In this way, a problem solved using a divide and conquer strategy can be expressed by a function whose arguments may be evaluated in parallel. Customers are the mechanism used for synchronizing the results obtained in the evaluation of the different arguments. Moreover,

customers allow a higher computational power because of the actor that is solving the problem do not become blocked waiting for the results. Customers will wait for them.

Let us consider the calculus of n! using the divide and conquer strategy. The whole problem is solved by considering n!= nl *n2, where nl =jloor(n/2)! and n2=lfloor(nI2)+1] * lfloor(n/2)+2] *...* n.

A customer actor is responsible for synchronizing the replies obtained as a result of the evaluation of the n l *n2 product. The customer calculates the product and send the result to its acquaintance which can be either another customer or the client actor which originated the factorial chain. n l and n2 may be in turn split up following the same strategy.

DEFINE ACTOR Customer; LOCALS

"ERFACE ACTOR target;

method init(ACT0R); method done(1ong int);

WHEN init(tg) + target=tg; WHEN done(k) + ;

ACTIONS

WAITFOR

END WAITFOR; END ACTOR Customer.

WHEN done(v) 3 target!done(k*v);

Figure 1

Figure 1 depicts a customer actor class and figure 2 shows the factorial actor class whose behaviour is described above. The result of creating new customers is that different requests to the factorial actor (and in consequence any problem solved using a divide and conquer paradigm) can be evaluated concurrently. Note in figure 1 the change of behaviour as a result of the done request as we explain in [lo]. Note also in figure 2 how the factorial actor is not blocked waiting for the result. Instead, the new customer created dynamically will wait for the evaluation of nl and n2.

Figure 3 shows an actor event diagram [2] corresponding with the computation of a call to the factorial actor performed by certain client

fact!compute(l,3) reply to @self. Vertical lines identify the life time of an actor. Dashed

lines represent the actor creation and solid lines depict communication. At the most right vertical lines we show the current message and the current value of the @reply variable.

424

DEFINEi ACTOR F;ictorial unserialized, INTERFACE

method compute(1ong int,long int); ACTIONS

WHEN compute(Eo,hi) 3 { long int mid; Customer cust; if (lo==hi) @reply!done(lo); else {

mi=(lo+hi)/2; CreateActor(cust,init(@repl y)); @self!compute:(lo,mi) reply to cust; @self!compute:(mi+l,hi) reply to cust;

I 1

END ACTOR Factorial.

cust (client) \4- I

K& client

Figure 2

\

4

cust' (CU! /

\

Figure 3

4.2: The actor-group

An actor-group is currently1 implemented in ALBA my means of a meta-actor which contains a set of actors with the same behaviour for receiving messages.

If the Operating System supports mechanisms for implementing process groups, the actor-group would be integrated in ALBA. Currently, the HELIOS O.S. does not support such a facility.

An actor-group must provide, at least, the following set of operations:

Creation of an actor group with its corresponding capabilities - Create .4ctorGroup() . Insertion of new actors or actor-groups - add(). Removal of actors ot actor-groups - remove().

9 Sending of messages to one of the members in the group undeterministilcally - send(). Broadcasting of messages to all members in the group - broadcast().

Assume that fact-agr is an actor-group containing instances of the NewFactorial class coded in figure 4.

DEFINE ACTOR NewFactorial; ...

WHEN conipute(lo,hi,target) { long int mid Customer cust; if (lo==hiJi target!done(lo); else {

mi=(lot hi)/2; CreateActor(cust,init(target)); Fact-agr ! send(compute(lo,mi,cust)); Fact-agr ! send(compute(mi+ 1 ,hi,cust));

I I

END ACTOR NewFactorial.

Figure 4

The behaviour of the solution addressed in figure 4 would be the same as L figure 2 if the actor-group has an unique instance of the NewFactorial actor. However, if we group several instances of the NewFactorial in the group, we gain computaitional power.

Although [3] defines well the Actorspace, the way on which actors belonging to an Actorspace collect answers is not outlined. We present a way to do that using customers. Note how the customer actor in figure 4 is the same as in figure 1.

Figure 5 depicts a piece of ALBA code for interacting with an actor-group. Firstly, we constrain to the members of the NewFactorial and Client classes the capability for sending messages to the group. Once New-factorial instances have been created and added into the group, we send as many request to factorial as desired. Finally, the client of the group wails for the answers. It also must be noted than an actor-group is in turn an actor and, in consequence, it has all the features that present actors in ALBA. In particular, the mail-address may be freely communicated to any other actors. Only actors with enough capabilities can interact with the group.

425

Create Acto&roup(Fact-agr,"NewFactorial/client"); I* creation of as many new-factorial instances as desired and adding them into the group *I

Fact-agr! send(compute( 1 ,n,@self)); I* other statements *I WAITFOR

END WAITFOR ;

......

WHEN done (k) + printf("%ld,k);

Figure 5

Figure 6 shows the actor event diagram corresponding with the computation of a factorial using an actor-group. There are two instances of the new-factorial class, namely fact i and fact2 into the group. Computation starts by a call such as

fact-agr!send(compute(l,S,@seM).

p' (1,3,client)

(1,2,cust)

(3,3,cust)

(1,l ,cud)

(2,2,cus t')

client

Figure 6 5: The Actor-Tuplespace

The goal of the Actor-Tuplespace is to provide a model thought for communicating and synchronizing objects in any object-based concurrent system. It combines the Actor and the Linda models.

The Actor-Tuplespace paradigm (A-TS) proportions security against arbitrary readers of tuples by means of capabilities expressed in tuples.

An A-TS is a computational passive container of tuples handled by an actor-group or a set of actors associated to it. In the following, we call them coordinators of the A-TS .

In order to understand the A-TS model, it should be viewed from two different perspectives: the client of A-TS and the coordinators.

From the client point of view, the A-TS stores tasks to be done by the coordinator. Demands of these tasks are performed by inserting tuples in the A-TS. As it will be shown, these tuples include across theirs fields the task to be done.

From the coordinators perspective, the A-TS is used to retrieve the client demands and to provide a mechanism to synchronize themselves.

A tuple in the A-TS is defined as a list of fields with the following pattern:

(capability, {target-actor *}, {method-call 1 *}) Clients use the out() primitive for putting tasks into

the A-TS whereas coordinators use out(), in( ) and rd() primitives to handle the A-TS.

The A-TS model is currently being implemented in ALBA as a meta-actor which provide,at least, the following set of primitives:

Creation of an A-TS with its corresponding capabilities Create ActorTupleSpace 0. Insertion of a tuple - out 0. Retrieval of a tuple - in(). Read of a tuple without deleting it - rd 0. The meaning of out(), in() and rd() primitives is the

same as in Linda. In this way a client is only allowed to issue out() primitives whereas coordinators can use the whole set.

As an example of using the A-TS model, let us consider an A-TS coordinated by actors of a "printer" class. Authorized clients can demand a requirement to print, for instance, a file named "myfile" by simply issuing a call such as

out('brinter",* ,print(myfile)) If coordinators have a method matching the pattern p r i n t ( f i l e n a m e ) , the above tuple will match a ('@-inter",*,*) or (')rinter",*,printCfilename)) tuple put into the A-TS by means of the in() primitive.

The A-TS provides a simple way of specification of synchronization constraints among actors. Thus, distributed data structures and inheritance mechanism may be defined by means of the A-TS. Figure 7 illustrates the use of the A-TS defining a distributed stack. Note that when the stack is empty, only a push message is accepted Otherwise, only the stack-node actor on the top of the stack has the permissions for processing messages sent to

426

the stack. Inheritance is beyoind the scope of this paper. The creator of the stack A-TS would have a code such as

Create Actor-TupleSpace(ts,"client/stack-node"); CreateActor (sn,init(NULLjts));

and clients interact with stack through the out() primitive putting tuples in the form ts!out("stack-node",*.push(n)) or ts!out("stack-node",* ,pop).

DEFINE ACTOR stack-ntxle; LOCALS

in t exit=O; INTERFACE

method init(int,TUPLE--SPACE) method continue; method push(&); method pop;

WHEN init(info,ts) =+ ([ ACTIONS

do{ if (info==NuLL)

else ts?in("stack-nodle",*,*); WAITFOR

ts?in("stack-node".,* ,push(int));

WHEN push(new-info) - { stack-ncde p; CreateActor@,ini t(new-info,ts)); &?in(" Stack-nodeP ,@ se1 f,continue); WAITFOR

END WAITFOR; WHEN continue + ;

1 W" POP * (

@sender!done(infiD); @!out( "stack-node",@creator,continue); exit=l;

) until exit;

END ACTOR.

END WAITFOR;

1

Figure 7 There a~ significant differences with the Linda Model:

(1) It does not exist only one TupleSpace. A-TS are actors!!. We may create as many as desired for synchronizing other actors. Mail-addresses of A-TS may be freely communicated to other actors, although only authorized clients may send request (with the out( ) primitive) the A-TS. (2) In the Linda model, tuples contains values. In the A- TS, tuples contains messages that actors pick up for

processing them. Note how each tuple contains method calls.

6: Conclusions We have shown how ALBA offers a programming

environment suitable for the development of parallel and distributed applications. The actor-group concept provides a high-level communic:ation abstraction to simplify the interaction of clients with a group of servers.

The Actor-Tuplespace seems to be an attractive idea for synchronizing a collection of actors because it provides a simple way of specification of synchronization constraints among a set of actors. In addition to that, Actor- TuplaSpaces offers a via for solving inheritance in object- based concurrent programming because of the way coordinators share the Actor-TuplaSpace.

References 1.

2.

3.

4.

5.

6.

7.

8.

9.

10.

11.

12.

13.

G. Agha, ACTORS: A Model of Concurrent Computation in Distributed Systems, The MIT Press, 1986. G. Agha, Concurrent Object-Oriented Programming, Communications of the ACM, vol. 33(9),1990. G. Agha and C.J. Callsen, Actorspace: An Open Distributed Programiming Paradigm, In Proceedings of the Fourth ACM SIlGPLAN Symposioum on Principles and Practice of Paradlel Programming. ACM SIGPLAN Notices, vol 28(7), 1993. M. Barrena, J. Herndndez, et. al., QUATRO: A Parallel Database Management Model, Technical Report nQ FIM66.1/ARQ/92. Polytechnic University, Madrid 1992. N. Carrier0 and D. Gelernter, How to Write Parallel Programs: A Guide to the Perplexed, ACM Computing Surveys, vol 21(3), 1989. Special Issue of the Comm. of the ACM, Concurrent Object-Oriented Programming, vol. 36(9), 1993. N. Gehani, Broadcasting Sequential Processes, IEEE Transaction on Software Engineering. July 1984. J. Herndndez, P. de Miguel, M. Barrena, J.M. Martinez, A. Polo and M. Nieto, ALBA A Parallel Language Based on Actors, ACM SIGtPLAN Notices Vo1.28(4), 1993 J. Hernhndez, P. de Miguel, et. al., A Programming Model for Distributed Memory Architectures, Proceedings of the Second International Conference on Parallel and Computing Technologies, PACT'93, Moscow 1993. J. Hernbndez, P. (de Miguel et.al., Implementation details of ALBA in a Transputer Machine, Proceedings of the Short Notes Programme of the 19th. Euromicro Conference, Barcelona (Spain) September 1993. G. Lapalme, PLASMA-11: an Actor Approach to Concurrent Programming, Proceedings of the ACM SIGPLAN Workshop on Object-Based Concurrent Programming. Vol 24(4), 1989. L. Liang, et. al., Process Groups and Group Communications: Cllassifications and Requirements, IEEE Computer, Feb~:uary 1990. A. Yonezawa and M. Tokoro, editors, Object-Oriented Concurrent Programming, The MIT Press 1987.

427