A Proposal to Improve Reusability in a Language

A Proposal to Improve Reusability in a Language based on the Occam-CSP Model F. Araque, M. Capel, J.M. Mantas, A. Palma Dpto. de Lenguajes y Sistemas Informaticos E.T.S. Ingeniera Informatica Universidad de Granada Avda. Andaluca 38, 18071 - Granada email: [email protected]

Abstract The need to declare channels as global objects of the applications implemented according to the Distributed Programming Occam-CSP model, limits the desirable reusability of the software-modules of the said applications. The integration of other languages that follow the OO paradigm is not easy either. In this paper, easy solutions are proposed to augment the reusability of languages that follow the existing model based on a class of modules called ODAs and on a previously existing language that implement the above-mentioned modules in a multicomputer based on a Transputer platform.

1. Introduction It is well known that multicomputers are nowadays the most important technological option to answer the increasing demand of speed and memory of current applications. The absence of a general reference language for programming with this kind of architecture, has been the cause of the overabundance of distributed language proposals in the last fteen years. Many of these proposals have had a wide distribution, such as PVM [5], but they don't allow the veri cation of the total correctness of programs. Others, even though carried out by important scientists, e.g. Joyce [6], haven't achieved the necessary diusion to be implemented in concrete architectures. And classical languages, like Ada [3], are not adequate to be implemented eciently without severely restricting the language constructions in a distributed system. None of the aforementioned problems aect the Occam-CSP model of distributed programming. The Occam [2] language is an almost complete implementa-

tion of the CSP [1] model and has been used as a reference language to develop the SGS-Thomson (formerly called Inmos) Transputer processor family. The basis for the development of Software Engineering tools, which allows one to derive high quality and secure programs in Occam for multicomputers, has been established based on the formal semantics of the language derived from C.A.R. Hoare's work in the last decade [8]. Traditionally it has been argued that the lack of reusability of the Occam-CSP model is one of the drawbacks which prevents a widespread use of programming following this model. The code of a module or a process, etc. needs to access global channels which communicate processes in the same or in other processors, therefore the reusability of programs developed with the aforementioned model is limited. Nevertheless, this drawback may be resolved by separating the con guration of the channels from the programming of the application's modules. This paper proposes a method to overcome this drawback by following this idea. The integration of Object-Oriented Programming (OOP) concepts with the Occam-CSP model in order to obtain software reusability presents various drawbacks. The Occam-CSP model is mainly static (i.e. all the components should be xed before program execution), as opposed to the late binding of the OOP. Additionally, the communication model of the OccamCSP is point-to-point synchronous message passing, whereas the OOP employs a client-server communication scheme. The parallel granularity unit is at instruction level in Occam, whereas in the case of OO languages it should be at a process or object level. On the other hand, the object-based programming model assumes that aspects referring to the con guration, distribution, mobility, etc, of the objects have to be con-

cealed from the user programs. All this seems to point out to the incompatibility of both models. Our proposal attempts to demonstrate a technique to achieve reusability in distributed applications. This has been developed using a class of modules called ODAs that are used to encapsulate abstract data types, among other information, in SPMD-distributed applications. A language that uses these modules, has been presented in previous papers [11], [12]. In our model, communications are carried out through global channels declared according to the Occam model, while object reusability is achieved using ODA modules, as will be demonstrated. This has been carried out on various platforms, while currently a Telmat TN310 multicomputer with 16 T9000 processors is being used. In the next section both the distributed programming model based on ODAs and its implementation in an Occam-transputer platform will be explained. In order to solve some of the problems that arise due to the direct implementation in Occam of applications based on ODAs, a previously proposed language [11],[12] that allows ODAs-description is used and the most signi cant aspects will be revised at the end of section 2. In the third section, some of the aforementioned language characteristics that improve reusability will be presented.

2. Programming Model: Distributed Active Objects An ODA module will be implemented as an object whose code is replicated into all the nodes of the multicomputer. The dierent replicas of the object (see g. 1) will communicate each other in order to: 

maintain the coherency of the global Abstract Data Type implementation,



implement the object's operations. ODA1 COMMUNICATION STRUCTURE

ODA1 replica

ODA1 replica

ODA2 COMMUNICATION STRUCTURE

ODA2 replica application process replica

PROCESSOR 0

ODA1 replica ODA2 replica

ODA2 replica application process replica

PROCESSOR 1 Figure 1

application process replica

PROCESSOR N-1

The communication code of the application is encapsulated in the ODAs employing high level constructions of a speci c language [12]. By means of messages passed between the replicas of the ODAs, a distributed computation model is achieved in that the application processes only carry out local communication and the ODAs are charged for remote communication. The way in which dierent ODA-replicas connect and communicate with each other will depend on the represented data type and will re ect the object's own communication structure. The ODA modules are used to implement the code of the operations while also providing their users access to a series of operations which belong to an abstract data type. These operations have a semantic of remote calls which means that one ODA-replica attends operation requests while the clients await a message with results.

2.1. Distributed application building in Occam In order to implement each ODA-replica in Occam 2, a generic procedure is necessary whose formal parameters are:  A series of channels for the communication with other ODA-replicas of the same type.  For each operation, an array of channels for the communication with the application processes.  Two parameters that will contain the current values of each replica identi er (REP.ID) and the number of replicas (NODES). In a similar way, the application process is described as an Occam procedure whose formal parameters are the parameters REP.ID, NODES and, for every ODA, a pair of channels for each operation. The procedures that implement both ODA-replicas and application processes are compiled and linked separately. A complete distributed application is described in a con guration le (see g. 2), in which the parallel components to be executed in each processor are speci ed and the channels needed to correctly connect the dierent processes according to the logical communication structure of the application are declared. The existence of this "con guration phase" is a way to achieve the reusability of components compiled and linked in the distributed applications, or even considering the possibility of having a library of said components.

2.2. ODAs Description Language To use the ODA modules in the applications in a

exible way, a language to describe these modules has

PROC oda2.replica ([]CHAN OF oda2.dif canal.dif, Pi PROC oda1.replica ([]CHAN OF oda1.dif canal.dif, []CHAN OF oda1.op1 canal.op1, []CHAN OF oda1.op2 canal.op2, : VAL INT rep.id, nodes) ... :

compiler

ODA-REPLICAS CODE PROC app.replica ([2]CHAN OF oda1.op1 c.oda1.op1, [2]CHAN OF oda1.op2 c.oda1.op2, [2]CHAN OF oda2.op1 c.oda2.op1, [2]CHAN OF oda2.op2 c.oda2.op2, VAL INT rep.id, nodes) ... :

linker

COMPILED AND LINKED MODULES

APPLICATION PROCESS REPLICA CODE NETWORK - - hardware description ... CONFIG - - software description VAL nodes IS . . . : ... Channel Declarations PAR rep.id= 0 FOR nodes PROCESSOR rep.id ... Channel Declarations PAR app.replica (...) oda1.replica (...) oda2.replica (...)

configurer

ODA1 replica

ODA1 replica ODA2 replica

application process replica

PROCESSOR 0

ODA1 replica ODA2 replica

ODA2 replica

application process replica

PROCESSOR 1

application process replica

PROCESSOR N-1

DISTRIBUTED APPLICATION

CONFIGURATION FILE

We distinguish between an ODA declaration which makes the de nition of an ODA accesible to its users, and ODA instantation, where a speci c implementation is assigned to the previously declared ODA. Declarations and instantiations are made in a separate module: the application process. We decided that this module will not be reusable, since it seems logical to us that a substitution of the ODA module implies a modi cation of the user application program code. Reusability is achieved at the ODA level, and the responsibility of generating automatically the con guration le is left to the con gurer (see g. 2). De nition and implementation parts of the ODAs remain unlinked until the moment that they are declared and instantiated.

Figure 2

ODA.DEFINITION def.oda2 ( ) ODA.DEFINITION def.oda1 ( ) DIFFUSION.MESSAGES CHAN OF oda1.dif canal.in, canal.out: TOPOLOGY CONNECT canal.in, canal.out TO rep.id-1, rep.id+ 1 SHARED.OBJECTS CALL op1 ( . . .) : CALL op2 ( . . .) :

ODA-REPLICAS CODE

ODA DEFINITIONS

been proposed, which should allow the programmer of distributed applications freedom from low level details thus improving the programmability and code reusability. The ODA description language has been shown in previous papers [11],[12]. In the notation of the language the description of an ODA-module is carried out in two separate parts: 1. De nition. 





For every replica, channels that allow communication with other replicas of the same ODA assigned to dierent processors are declared, making use of the communication channels previously mentioned. The ODA communication structure is described. Speci cally, the way in which different ODA-replicas will be connected. The interface for the ODA operations is speci ed in order to have a similar notation to the remote call channels of Occam 3 [14], conforming more to its semantics.

ODA.IMPLEMENTATION imp.oda1 ( ) USE ODA def.oda1: ...

ODAs precompiler

ODA IMPLEMENTATIONS APPLICATION app NODES IS . . . : ODA def.oda1 oda1: ODA def.oda2 oda2: oda1( ) IMPLEMENTED imp.oda1( ) oda2( ) IMPLEMENTED imp.oda2( ) ... : APPLICATION PROCESS DESCRIPTION

The ODA-replicas code that implements the operations of the ODA are described.

CONFIGURATION FILE

Figure 3

3. Issues of Reusability in the Language 3.1. Use of the same de nition with dierent implementations After declaring an ODA, a set of operations is offered to its possible users. In the following example, we introduce an ODA de nition that represents a distributed integer with two operations: read and write.

2. The implementation. 

APPLICATION PROCESS REPLICA CODE

ODA.DEFINITION distr.integer () PROTOCOL integer IS INT:

DIFFUSION.MESSAGES [NODES-1][2] CHAN OF integer integer.diff: TOPOLOGY -- full connected topology DO i=0 FOR NODES-1 DO j=0 FOR 2 CONNECT integer.diff[i][j] TO ((REP.ID+1)+i)\NODES SHARED.OBJECTS CALL read (RESULT INT data ): CALL write (VAL INT data):

Any possible implementation for will include this clause:

distr.integer

USE ODA distr.integer:

We can have dierent implementations of ODAmodules that represent a distributed integer. These implementations assume both the same interface and communication structure as if they used the same definition. We would be able to have other implementations that provide dierent functionability to the ODA operations and that will be used for speci c applications. This would allow us to manage a distributed global variable of integer type. Using this implementation (called ordinary.integer) the invocation of for example, the write operation, would involve updating the locally stored value in any of the replicas while this value is dierent than the previously stored one. Another possibility would be to have an implementation (called smallest.integer) which would cause the update in any of the local replicas where the desired value is lower than the one stored. The interface and communication structure of this new implementation would be the same although the semantics of write operation would be slightly dierent. In the next application process, two ODAs, e1 and e2, are declared with a distr.integer de nition. In the instatiation, the ordinary.integer implementation is assigned to e1 and the smallest.integer implementation to e2: APPLICATION example NODES IS ...: ODA distr.integer e1, e2: DO e1() IMPLEMENTED ordinary.integer() e2() IMPLEMENTED smallest.integer() SEQ -- Give an initial value to e1 e1{write}(0) -- Give an initial value to e2 e2{write}(known.value) ... etc...

The declared ODAs allow us to keep two types of globally distributed variables of integer type, and both can be used in distributed applications according to the required functionability.

3.2. ODAs parameterization In the ODA module de nition heading, formal parameters can be declared. These parameters, together with NODES and REP.ID, allow the "skeleton" description of the distributed object communication structure which will be instantiated in the con guration phase, when these parameters take particular values. In order to illustrate the application of our scheme, we will show some details about the implementation of an n-way lter algorithm in a multicomputer. We will implement a particular case of the algorithm, in which every leaf node in a tree, de ned with a xed branch degree for all the nodes, takes positive integer values from a le and distributes the said values toward its parent node. Internal nodes in the tree compute the largest values among those obtained from its sons and send the result to its parent node. In order to encapsulate communication requirements of the algorithm, we have made the following ODA-module de nition that represents a type of distributed object with uniform n-ary tree topology. In this de nition, the branch degree of each node (n=branch degree), is declared as a formal parameter in the heading. -- Uniform n-ary tree ODA.DEFINITION n.tree (VAL INT branch.degree) PROTOCOL n.protoc IS ...: DIFFUSION.MESSAGES [branch.degree]CHAN OF n.protoc son.c: CHAN OF n.protoc parent.c: CHAN OF n.protoc before.c, next.c: TOPOLOGY DO IF is.internal.node DO j=0 FOR branch.degree CONNECT son.c[j] TO left.son.node+j IF NOT is.root.node CONNECT parent.c TO parent.node SHARED.OBJECTS CALL receive.data (RESULT INT data): CALL send.data (VAL INT data):

As can be seen in this de nition, an array of channels whose sizes are equal to branch.degree parameter (to communicate with the sons of the current node), a channel parent.c (to communicate with the parent node) and two other channels, before.c and next.c (its usefulness will be shown later), are declared. These channels will be mapped onto a uniform n-ary tree topology in the con guration phase. NODES = 13 branch.degree = 3

0

1

4

5

2

6

7

8

clauses as can be seen in the threading.n.tree ODA de nition.

10

11

2

1

3

4

5

6

threading.n.tree topology Figure 5

3

9

NODES = 7 branch.degree = 2

0

12

n.tree topology Figure 4

The

branch.degree parameter, together with the parameter, allow us to de ne objects with tree topology that can be adapted in a exible way for multiple distributed applications which request services of an object with this communication structure. Once the ODA de nition has been speci ed, a compatible implementation which shows the required communication in the lter algorithm, should be de ned.

NODES

ODA.IMPLEMENTATION filter.imp() USE ODA n.tree: ... etc...

ODA.DEFINITION threading.n.tree REDEFINES n.tree TOPOLOGY DO IF is.leaf.node IF (REP.IDprimer.nodo.hoja) AND (REP.IDultimo.nodo.hoja) CONNECT before.c,next.c TO before.node,next.node (REP.ID=first.leaf.node) CONNECT before.c,next.c TO last.leaf.node,next.node (REP.ID=last.leaf.node) CONNECT before.c,next.c TO before.node,first.leaf.node

INTERFACE OPERATIONS receive.data (v) send.data (v)

3.3. Topologies rede nition New de nitions of the TOPOLOGY section can be created starting from previously existing de nitions. An easy example showing how this would be possible is the following: suppose we wish to incorporate a graceful termination detection mechanism in the lter processes which will be initiated when any given leaf node receives a particular type of integer data (e.g. any negative integer). In this case, we need a communication structure that will permit the proper termination of the leaf nodes, so that later the internal nodes will also be terminated in an orderly way. This is accomplished by connecting leaf nodes in a ring shape. This can be achieved adapting the n.tree de nition topology to a new context by assigning before.c and next.c channels in leaf nodes level (see g. 5). These channel assignments can be carried out using CONNECT

... ...

... Figure 6

Using this mechanism, we can create ODA de nitions from the previously existing ones in a hierarchical way (see g. 6). A topology rede nition will not add any new aspect to the ODA module interface, but will only modify the object communication patterns. In this way, reusability of previous de nitions will be attained. We call the set of de nitions obtained from a given de nition a family of ODA de nitions. The variations between one de nition and another in a family only refer to the communication structure de ned to communicate the dierent replicas of an ODA. The ODA de nitions in a family also maintain the same interface. As a general rule, all the de nitions in a family can be instantiated with an implementation that is compatible with the communication features that characterize the said family.

4. Conclusions Easy solutions have been established to augment the reusability of software components developed with a language that follows the Occam-CSP model. The said solutions consist essentially of three features of reusability that can be applied in the distributed applications development. 1. Reusability based on the de nition separated from the interface consisting of replacing the ODA module implementation, so it always maintains the same interface and object communication structure that the said module represents. 2. Reusability based on ODA module parameterization consisting of parameterizing the heading of the de nition modules of the ODAs; these parameters will be instantiated in the con guration phase of a given application. 3. Reusability based on the adaptation of the communication structure consisting of a statical rede nition of the ODA communication topology, which will aect the aforementioned communication structure thus allowing the same implementation to remain. Furthermore, we have given some outlines as to the ODA description language that has been previously proposed in the works of our team in order to show practical applications of a concept similar to the distributed abstract data type, which is necessary to obtain the integration between the object-based languages and others that follow the Occam-CSP model.

5. References 1. C.A.R. Hoare. "Communicating Sequential Processes". Communications of the ACM, v.21, n.8, pp.666-677, 1978. 2. Inmos, Lmtd. "Occam Programming Manual". Prentice-Hall, London, 1984. 3. Atkinson, C., Moreton, T. Natali, A. "Ada for distributed systems". Cambridge University Press, 1988. 4. Baumgarten, U. "Distributed systems and Adacurrent projects and approaches comparative study's results". Ada Europe international conference, Athens, Greece, May 1991, pp.260-278. 5. Geist, G.A., Sunderam, V.S. "Experiences with Network-Based Concurrent Computing on the PVM System". Concurrency: Practice and Experience, v.4, n.4., pp.293-311, 1992. 6. Brinch-Hansen, P. "The Joyce Language Report". Software Practice and Experience, v.19, n.6, pp.553578, 1989. 7. Brinch-Hansen, P. "Super-Pascal a publication language for parallel scienti c computing". Concurrency: practice and experience, v.6, n.5, pp.461-483, 1994. 8. Hoare, C.A.R. "Communicating Sequential Processes". Prentice-Hall, 1985. 9. Brookes, S.D., Hoare, C.A.R. ,Roscoe, A.W. "A Theory Model for Communicating Processes". Communications of the ACM, v.32, n.3, pp.560-599, 1984. 10. Goldsmith, M.H., Roscoe, A.W., Scott, B.G.O. "A Semantic Model for Occam 2". Transputer Applications and Systems'93. IOS Press, 1993, pp.965-980. 11. Capel, M., Troya, J.M. "An Object Based Tool and Methodological Approach for Distributed Programming". Software Concepts and Tools, v.15, n.4, pp.177-195,1994. 12. Capel, M., Troya, J.M., Palma, A. "Distributed Active Objects: A MethodologicalProposal and Tool for Distributed programming with Transputer Systems".Microprocessing and Microprogramming, v.38, pp.197-204, 1993. 13. Sakdavong, J.C., Bahsoun, J.P., Feraud, L. "Con guration Classes: An Object Oriented Paradigm for Distributed Programming". IWOOOS'95, Lund,Sweden, Aug.1995. IEEE proceedings., pp.200-209. 14. Geo Barret. "Occam 3 reference manual". Inmos Lmtd, 1992.