A new proposal of Concurrent Process Calculus

A new proposal of Concurrent Process Calculus? Salvador Lucas and Javier Oliver Departamento de Sistemas Informaticos y Computacion Universidad Politecnica de Valencia Camino de Vera s/n, Apdo. 22012, 46020 Valencia, Spain. e.mail:fslucas,[email protected] In this paper, we present a new calculus to model concurrent systems, the Parallel Label-Selective -calculus. This calculus integrates the (functional) expressiveness of the -calculus in a uni ed framework with some powerful features for expressing communication actions and supporting the independence of processes which can be a main source of improvement when performing parallel computations.

Abstract.

Concurrency, Extensions of -calculus, Functional Programming, Process Algebra.

Keywords:

1 Introduction A computational model links the software and hardware description levels of computer systems, in order to analyze the correctness, completeness or eciency of programs which we want to run on a given machine. General agreement seems to exist on the main features that a model of concurrency should include: a concurrent system is a community of sequential processes which can work in an independent or interdependent fashion [3]. Concurrency and communication express independency and interdependency: concurrent processes (independently) deal with their respective tasks until a cooperation (i.e., a communication) is needed. Functional languages provide an excellent tool for parallel computation because there are no side-eects. Functional programs can be evaluated sequentially or in parallel without changing their denotational or declarative semantics. Nevertheless, the inclusion of constructs for explicit concurrency enhances the expressiveness of executable speci cation languages as there are programs which can best be described as a composition of parallel processes [8]. Sequential (functional) computation is traditionally captured by the -calculus [2] as Berry showed in [4]. Function declarations and their application to data (which can eventually be other functions) is supported by the language. Thus, an important challenge for researchers was to nd a framework for the concurrency and the communication between processes similar to the -calculus, [1, 5, 7, 10, 11]. We introduce the Parallel Label-Selective -calculus, LCEP2 , to model concurrency and communication from a functional perspective. The expressiveness of the -calculus is integrated within a uni ed framework with powerful features to explicitly express the communication actions and the independence of processes, which are the main source of improvements when performing parallel computations. Since our framework originates from the -calculus, we chose a ? 2

This work has been partially supported by CICYT, TIC 95-0433-C03-03. -Calculo Etiquetado Paralelo.

functional point of view to describe concurrency. The basic feature of functional programming is the application of functions to values. In this setting, communication can be viewed as argument instantiation, if we embed the adequate means to provide `remote' instantiation of parameters. The formal parameter takes the role of a communication channel. The need for an ordered matching of the formal and actual parameters is also relaxed to bring up the necessary independence of parallel systems. This allows us to speak of the sequential application of a function to its parameters instead of the standard application, and the parallel application of a function to remote, possibly committing parameters which in this case models the standard communication. The idea of how long and to what extent a remote parameter can be instantiated in a function call is captured by means of the notion of tunnel, which is novel in the literature. This paper is organized as follows: Section 2 describes the language and the reduction system of the calculus. Section 3 gives a general idea of using LCEP as a target language to mechanize functional concurrent languages. The last section oers some conclusions and suggestions for future work.

2 The calculus LCEP is a calculus which originated from a previous proposal by H. At-Kaci, the Label-Selective -calculus [1], an extension of the -calculus in which function arguments are selected by labels. Symbolic and numeric labels can be used to name the communication channels. This has not been possible in other proposals and permits the use of currying and labeled speci cation of parameters. It makes the ordering of the actual parameters in a function call independent of the presentation order of the formal parameters in the de nition.

Example 1 Let f = xy:x 0 y be a -term. In LCEP, we can de ne the function f as f (p; q) = p x:q y:x 0 y. We name the formal parameters of f by means of labels p; q. We can specify the application of f to parameters a; b by giving its destination in two ways: by explicitly indicating either the number of the formal parameters, f (b ! 2; a ! 1) = f (a; b), or the name of the formal parameters, f (b ! q; a ! p) = f (a; b). However, the Label-Selective -calculus is not very appropriate for concurrency: it lacks both a non-deterministic choice and explicit parallelism operators. The calculus supports concurrency among dierent channels, but it is not able to describe, for example, alternative choices over the same channel. For instance, the dining philosophers problem, cannot be modeled using Label-Selective calculus because non-deterministic choice and parallelism operators are both needed [12]. They are introduced by following Milner's -calculus [11].

2.1 Description of LCEP

Let V = fx; y; z; : : :g be a set of variables, and C = fa; b; c; : : :g be a set of constants. P represents a channel name from a set of labels L = IN [ S , where m; n; : : : denote numerical labels taken from IN (the set of natural numbers), S = fp; q; : : :g is a set of symbolic labels, and IN \ S = ;. Constants, variables and the null process (denoted by 0) form the atomic elements of the language. The language of the formal system that we present is M. It is de ned as follows: M ::= 0 j a j x j P x:M j Pb M j (M k M ) j (M  M ) j (M + M ) j !M P ::= number j symbol

In concurrent programming, the terms M 2 M represent processes. Symbols  (sequential composition), k (parallel composition), + (nondeterministic choice)

and ! (replication) are considered as process constructors. The operators P x (abstraction or input) and Pb (parameter passing or output) are also considered as process constructors, whose eect over a process M is to de ne processes (P x:M and Pb M , respectively) which are involved in functional applications under certain given conditions. We consider a partial order relation, L on L. The numerical label 0 is the minimum of this poset. By analogy with -calculus, the process constructors can be viewed as symbols of a signature [9], that is, a set of function symbols, each of which has a xed arity. Symbols ; k; + are binary operations, !; P x and Pb are unary operations for all P 2 L and x 2 V , x; 0 are 0-ary operations for all x 2 V and we let P = fPb : P 2 Lg and 3 = fP x : (P 2 L) ^ (x 2 V )g be the set of output and input operations, respectively. The terms of this signature are called k -terms. We use the habitual notions of occurrence, set of occurrences, subterm, etc. (see [6] for complete de nitions). Terms are viewed as labeled trees in the usual way. Occurrences u; v; : : : are chains of positive natural numbers used to address subterms of t. They are ordered by: u  v, if 9w. u:w = v. We let u j v i u 6 v and v 6 u. O(t) denotes the set of occurrences of a term t. tju is the subterm at an occurrence u of t. t[s]u is the term t with the subterm at the occurrence u replaced with s. t[u] denotes the symbol which labels the root of tju .

k

8

8

8

P x 8

H

H

H

H

b P

M N Syntactical tree of the process P x:M

k PbN In the tree representation of a k -term A, a tuple = hu1; : : :; uni, ui 2 O(A) for 1  i  n is a path between the subprocesses M = Aju and N = Ajv (u; v disjoint occurrences), if is the shortest path in A verifying u1 = u0 and un = v0 whenever u = u0:i and v = v0 :j for some i; j 2 IN. We associate to the path of occurrences the path s = hs1 ; : : :; sni of symbols si = A[ui] rooted at these occurrences. For the sake of expressiveness, we usually identify s and . For example, in Figure 1 the path between the processes M and N is hP x; k; Pb i. The symbol  represents the least congruence over M, satisfying the following properties [11]: (M= ; k; 0) and (M= ,+; 0) are commutative monoids, M  0 = 0  M  M (identity), !M  M k !M , and b0 M  M . Fig. 1.

2.2 Reduction system Reductions between processes are de ned by an Inference System.

Axioms: First, sec and P model the dierent kinds of application.

1. sec : sequential application: (: : : + P x:M )  (Pb N  L + : : :) ! sec M [N=x]  L where P 2 L 0 f0g 2. P : parallel application, through the argument labeled with channel P : (: : : + P x:M ) k (Pb N  L + : : :) ! P M [N=x] k L where P 2 L 0 f0g and P is a family of rules indexed by L 0 f0g.

sec models the standard side-by-side application of a function to its arguments. A P rule expresses the `parallel' application of a function to (possibly many) committing arguments (on the same channel or name-of-formalparameter). Therefore, P expresses the classical communication process on a channel P , which can also be viewed from a functional perspective. Now the reordering rules extend the corresponding rules of the Label-Selective -calculus. They manage currying and unordered speci cation of arguments to a function (Example 1). 1. Reordering with numeric labels. Let m; n 2 IN 0 f0g, L; M; N 2 M, x; y 2 V : 1 : (m x:ny:M ) !1 (n y:m01 x:M ) if m L n 2 : mb M  nbN !2 bnN  md if m L n 01 M sec3 : (: : : + m x:M )  (nbN  L + : : :) !sec3 m01 x:(M  bnN )  L if m L n sec4 : (: : : + m x:M )  (nbN  L + : : :) !sec4 m x:(M  nd 01N )  L if m L n 2. Reordering with symbolic labels. Let p; q 2 S , L; M; N 2 M, x; y 2 V : 1 : (p x:q y:M ) !1 (q y:p x:M ) if p L q 2 : bp M  bq N !2 bq N  bp M if p L q sec3 : (: : :+p x:M )(bq N L+: : :) !sec3 p x:(M bq N )L if (p L q) _ (p L q) Rules: The structural inference rules are the following: ! M0 M ! M0 1 : M  M  2 : N ! M0  N N  M ! N  M0

M ! M0  :  x:M ! P x:M 0 P

b :

M ! M0 0 Pb M ! Pb M

! M0 k : M k M N ! M0 k N

N0 N0  M0 Congr : M  N NM ! ! M0

2.3 The concept of tunnel

We interpret the syntactical structure of the process as the `physical' means within which communication among the subprocesses is established. From this point of view, P application describes the communication between two communicating processes, P x:M and Pb N , on channel P linked by a single constructor of parallelism (k). From the functional point of view, this can be thought of as the remote instantiation of the actual parameter N in the body M of a function through the formal parameter P . We extend the scope of this simplest `remote' binding by our notion of tunnel. For example, in Figure 1, P x:M and Pb N communicate (using channel P ) through the (shortest) tunnel h k i. We extend the scope of P communication by means of the tunnel rule: k N ! P M 0 k N 0 T : QcM Mk Qc N ! QcM 0 k QcN 0 for Q1; Q2 2 L if P L Q1; Q2 1

2

P

1

2

T expresses the possibility of P communication between processes M and N , provided the following conditions are met: [T1] M and N are able to establish c1 M and Q c2 N are compound in parallel, and [T3] a P communication, [T2] Q the label P 2 L is greater than labels Q1 and Q2.

T1 is obviously necessary to make any communication feasible. T2 motivates the de nition of a syntactic object, namely the tunnel. It is possible to formalize it as a (special kind of) path in the syntactical tree of a process.

De nition 2.1 (Tunnel) Let A be a k -term. An elemental path in the syn-

tactical tree of A, = hu1; : : :; uni, ui 2 O(A), for 1  i  n is a tunnel i, n > 1 ) u1 j un and, being s = hs1 ; : : :; sn i, si 2 fkg [ P for i 1  i  n, and there is j , 1  j  n such that sj = k. De nition 2.2 (Tunnel location) Given a tunnel = hu1; : : :; uni in a k term A, the tunnel location  is the least occurrence of the elemental path of the tunnel:  = minfui j 1  i  ng. Note that A[ ] = k. Example 2 In the syntactical tree of C  Qc1 A k Qc2 (A1 k B ), we identify a tunnel. k Q





Q



Q



8 H

Q



8

Q H

8

c Q1

H

H

c Q2

a

8

8 a

a

8

k

A 

c



c



c

A1

B Fig. 2. Tunnel between processes A and B We are going to verify that, if A  P x:M and B  PbN , then a P communication is possible between A and B , in C . We assume that P  Qi for i = 1; 2. A and B de nition (1) A k B ! P A0 k B 0  k1 (2) A k A1 k B ! P A0 k A1 k B 0 c1 A0 k Q c2 (A1 k B 0 ) T (3) c Q1 A k c Q2 (A1 k B ) ! P Q c2 ; ki is a tunnel between nodes A and B . ; k In the syntactical tree of process C , hc Q1 ; Q

Having a tunnel between a sender and a receiver is not sucient to get communication. Condition T3 motivates the de nition of transparency of a tunnel. De nition 2.3 (P -transparent tunnel) Given a label P 2 L, a tunnel = hu1; : : :; uni is P -transparent if, being s = hs1 ; : : :; sni, for all i, 1  i  n, si 6= k ) P L Qi , where si = Qbi . De nition 2.4 (T -communicability) Let A be a k -term, M = Aju be a sender and N = Ajv be a receiver on a channel P . They are T -communicable on P if: 1. There exists a P -transparent tunnel between M and N . 2. Let  the location of . Then, 8w 2 O(A) : w   ) A[w] 2 fk; g[ 3 [P . Thus, parallel communication is a particular T -communication in which the tunnel between the communicating processes is the simplest one: = hki. From the de nition of tunnel transparency, it follows that, for all P 2 L, is always P -transparent.

3 Mechanizing functional concurrent languages using LCEP In this section, we illustrate the ability of LCEP for mechanizing a functional concurrent language. A functional program F is a set of function de nitions. Its execution is the evaluation of an expression E . Thus, the two main challenges

are the modelling of function de nitions and the modelling of the evaluation of expressions3 .

Modelling function de nitions. In a functional program, a k-ary (userde ned) function F can be speci ed as follows: def F (x1; : : :; xk ) = EF . Formal

parameters are named x1; : : :; xk and the expression EF describes the `actions' performed by F . EF is an expression in which calls to other functions can be found: basic functions from B1 ; : : :; Bm (for instance, if; +; 3), user-de ned functions from F1 ; : : :; Fn (even the same F function in recursive de nitions). A program with a goal expression E is translated into a k -term M = MB k MF k ME . It contains the representation of the basic functions MB , the program representation MF and the representation of the expression to be evaluated ME . The process MB is MB = MB1 k 1 1 1 k MBm , where MBi corresponds to the basic function Bi . MF is MF = MF1 k 1 1 1 k MFn , where MFi corresponds to the user-de ned function Fi. ME is  [E ], where the translation function  , mapping sentences of the language into k -expressions is de ned below. The structures of MBi 1  i  m and MFj 1  j  n are similar. We translate a (general) function de nition def H (x1; : : :; xk ) = EH , where H can be a basic or user-de ned function, into a k -term MH as follows: - MH =!Hb AH . AH is the abstraction of the function H . By using the function name H as a communication channel, we enable the communication mechanism to `send' the abstraction of H to the place where it is needed. By pre xing with the ! operator, we are able to obtain as many copies of AH as necessary. - AH = 1 x10 : 1 1 1 :1 x0k :SH has two parts. The rst one (1 x01 : 1 1 1 :1 x0k :) is devoted to receiving the arguments for the second one, SH , which translates the expresion EH . - Basic and user-de ned functions dier in the way that the process SH is de ned. A basic function B is prede ned: we let SB = CB  x10 1 1 1 x0k , where CB 2 C is a constant expressing the basic function. The evaluation of LCEP expressions involving these constants is managed in a special manner as we show below. - On the other hand, SF =  [EF ] for user-de ned functions F . Therefore, SF only represents the process which evaluates the expression EF de ning F . We complete the de nition of the translation function  as follows4:

Translation of expressions. An expression E is always viewed as a function call E = F (E1 ! j1; : : :; Ek ! jk ). Ei ! ji means that the i-th real parameter Ei corresponds to the ji -th formal parameter of F . Since the calculus expresses concurrency, the evaluation of a function call starts with the parallel evaluation of the actual parameters: -  [E ] = MArg k MAp . The evaluation of E splits up into two parts: the process evaluating the arguments, MArg , and the process which performs the application of the function to the (evaluated) arguments, MAp . - MAp = 1 10 : 1 1 1 :k k0 :F F 0:F 0  b110 1 1 1 b1k0 . Application of the function F consists in rst receiving the (evaluated) arguments E1; : : :; Ek through channels 1 ; : : :; k, next, receiving the abstraction of F through the channel F and then, 3

4

For reasons of brevity, the development is somewhat informal. We do not start from a real language, but rather from general sentences which have a syntax which is similar to almost every functional language. In a more complete treatment, we would be able to introduce many other features to increase parallelism.

applying it to the arguments. The labels i are considered to be fresh. - MArg = b1  [E1] k 1 1 1 k bk  [Ek ]. For each real parameter Ei , we build an evaluation environment5 bi  [Ei] for the process  [Ei] that represents the expression to evaluate. They are transparent for global scope processes but they are not transparent for the local processes. Therefore, the activation mechanism begins building an execution environment for each formal parameter and then communicates the nal result through the channels i . When the function arguments are evaluated, the execution continues applying the function de nition over them. The ordering of labels is essential in this scheme. We de ne the ordering L adequately to deal with these requirements. In the set of symbolic labels, we state  jL 0 , H jL H 0 and  L H for all labels ; 0 used in evaluation environments and basic or user-de ned functions H; H 0. The set of numeric labels inherits the standard ordering on IN. This de nition of the order L is also essential in managing recursivity.

Modelling the evaluation of expressions. Similar to the usual practice in

implementing pure functional languages [13], the execution of the process M on LCEP is composed of mixed steps. The dierent reduction rules apply in this precedence order: 1. Evaluation rules de ned for the basic functions: +, 0, etc.6 2. Reordering rules, 3. Sequential application and 4. Extended parallel -application, i.e. T -communication. H communications are (equally) prioritary for all basic or user-de ned function H . Tunnels located at outermost positions are (equally) prioritary. Evaluation rules are associated to basic functions. For example, denote as P LUS and MINUS the LCEP constants associated to the functions + and 0. Assuming that A; B are numbers, we have the following built-in evaluation rules: P LUS  A  B !evalP LUS A + B and MINUS  A  B !evalMINUS A 0 B . def F (x; y ) = x 0 y (as in Example 1). The associated process is MF =! Fb1 x:1 y:MINUS MINUS 0 :MINUS 0  b1 x  b1 y. Processes MP LUS and MMINUS are: MP LUS = ! Pd LUS (1 x1 :1 x2 :P LUS  x1  x2 ), and MMINUS = ! MINUS d (1 x1 :1 x2 :MINUS  x1  x2 ). Since !M  M k !M (see Section 2.1), we have the necessary copies of the processes. The evaluation of E = F (1 + 1 ! 2; 3 + 3 ! 1) is the execution of:

Example 3 Let F be de ned by

ME =  [F (1 + 1 ! 2; 3 + 3 ! 1)] = 1 10 :2 20 :F F 0 :(F 0  b2 10  b1 20 ) k k b1 (P LUS P LUS 00 :(P LUS 00  b1 1  b1 1)) k k b2 (P LUS P LUS :(P LUS  b1 3  b1 3))

k MMINUS k MF k ME In contrast to the -calculus where the abstractions must be kept in an environas follows: MP LUS

ment for use when they are needed, in LCEP it is possible to completely express the program as a term of the calculus. 5 6

In some cases, we simplify the expression of MAp and MArg by avoiding useless evaluations of the basic expressions: variables and constants (see below). Since LCEP includes the -calculus, it would be possible to express these operations as k -expressions, by de ning the natural numbers and operations as -terms. However, this is not used in real implementations and so we follow this standard approach.

4 Conclusions and future work LCEP has been presented in this paper. It is an extension of the -calculus to model concurrent systems. In our framework, communication is viewed as a special kind of function application. We distinguish between sequential and parallel application of functions to arguments. The tunnel concept is introduced to relate remote arguments and function abstractions. Also, one of the new features in relation to previous proposals is to allow the function arguments to be selected by means of both symbolic and numerical labels, which permits the use of currying. We are building a prototype of an abstract machine based on the formal system described here to execute programs written in a high-level language that allows us to express explicit parallelism.

References 1. H. At-Kaci and J. Garrigue. Label-Selective -Calculus: Syntax and Con uence. In R. K. Shyamasundar, editor, Foundations of Software Technology and Theoretical Computer Science, volume 761 of LNCS, pages 24{40. Springer-Verlag, Berlin, 1993. 2. H.P. Barendregt. The -calculus, its Syntax and Semantics, volume 103 of Studies in Logic and the Foundations of Mathematics. Elsevier Science Publishers, 1984 edition, Amsterdam, 1991. 3. M. Ben-Ari. Principles of Concurrent Programming. Englewood Clis: Prentice Hall, 1982. 4. G. Berry. Sequentialite de l'evaluation formelle des -expressions. In Proc. of 3-e Colloque International sur la Programmation, Dunod, Paris 1978. 5. G. Berry and G. Boudol. The Chemical Abstract Machine. In Proc. of 20'th ACM Annual Symp. on Principles of Programming Languages, pages 81{93, ACM Press, 1993. 6. N. Dershowitz and J.P. Jouannaud. Rewrite Systems. In J. van Leeuwen, editor, Handbook of Theoretical Computer Science, volume B: Formal Models and Semantics, pages 243{320. Elsevier, Amsterdam and the MIT Press, Cambridge, MA., 1990. 7. C.A.R. Hoare. Communicating Sequential Processes. Prentice Hall International, Great Britain, 1985. 8. M.P. Jones and P. Hudak. Implicit and explicit parallel programming in Haskell. Technical report, YALEU/DCS/RR-982, Yale University, New Haven, Connecticut, USA, August 1993. 9. R. Lalement. Computation as Logic. Prentice Hall International, Great Britain, 1993. 10. R. Milner. A Calculus of Communicating Systems. LNCS 92, 1980. Springer Verlag. 11. R. Milner. The polyadic -calculus: A tutorial. In F.L. Brauer, W. Bauer, and H. Schwichtenberg, editors, Logic and Algebra of Speci cations. Springer-Verlag, Berlin, 1993. 12. J. Oliver and S. Lucas. Survey of concurrent calculi. In M.A. Fernandez, J.M. Garca, J.A. Guerrero, and G. Moreno, editors, Nuevas tendencias en la Informatica: Arquitecturas Paralelas y Programacion Declarativa, pages 267{289, 1994. 13. S.L. Peyton-Jones. The implementation of functional programming languages. Prentice Hall International, Great Britain, 1987. A X macro package with LLNCS style This article was processed using the LT E