Local and Conditional Blackboard Operations in Log - Semantic Scholar

Local and Conditional Blackboard Operations in Log: Semantics, Applicability, and Implementation Koen De Bosschere Vakgroep Elektronica en Informatiesystemen Universiteit Gent, Belgium email: [email protected]

Jean-Marie Jacquet Institut d'Informatique University of Namur, Belgium email: [email protected]

Abstract: This paper discusses two extensions to the kernel Log language presented in [11]:

local blackboards and conditional access primitives. The former are needed to alleviate the blackboard communication bottleneck and to solve message naming con icts whereas the latter improves the message selection power of pattern matching or uni cation. We propose a syntax for both extensions, give their operational semantics, give an example of their use and nally discuss their implementation.

Keywords: Parallelism, concurrency, language design, blackboards, logic programming

1 Introduction The last decade has evidenced a clearly growing interest for coordination languages [10, 7, 6]. These languages, based on coarse grained application parallelism, have been proved to be a viable alternative to the exploitation of ne grained parallelism speci c to a particular language. They make explicit at the programming level the concepts of process creation, communication and synchronization and allow for the integration of several pieces of code written in various languages possibly related to such dierent programming styles as imperative programming, object-oriented programming, logic programming, functional programming and constraint programming. Moreover, the clear separation between communication and computation eases the task of coding large cooperative systems by allowing to rst focus on each part, considered in isolation assuming that the required data will eventually be available, and then, by simply composing these parts in parallel, making sure that suitable data are made available. Recently, we have proposed the Log framework [11]. As a snapshot, it uses a blackboard as

a communication medium which is accesses by (parallel) processes by means of tell, get and read operations. Another important feature following from Linda ([1]) is that (active) processes and (passive) data are handled in a completely similar way, namely, telling a process to create it, getting a process to kill it and reading a process to check its existence. A prototype implementation has proved the implementability of this language and the coding of several applications has revealed the ease of programming with it. This paper builds on this work to present two new mechanisms that are currently lacking, and that are of a practical necessity as well as not expressible by means of existing primitives. On the one hand, local blackboards are introduced to provide processes with private memories as well as to allow communication between processes to take place locally instead of globally. On the other hand, conditional operations are proposed in order to select data on the blackboard in a richer way than what can be achieved by uni cation only. It is here worth noting that the results of the paper are not limited to the context of Log

but are applicable to any Linda-based language and also to channel-based languages. Log is actually used here as a support for the presentation of our ideas and as a case study with respect to language expressiveness and implementation. Similarly, classical Horn clause programs are employed in Log but work under progress aims at proving that these ideas can be lifted to any other programming paradigm such as constraint programming, object-oriented programming, functional programming, and imperative programming. The work on local blackboards is related to multiple tuple spaces in Linda [9] and Polis Prolog [3]. Our model of local blackboards is completely unconstrained. That means that any process can use any blackboard that currently exists in the system. Hence, there are no hierarchical limitations imposed. The conditional blackboard access primitives are related to the preactivations in the Shared Prolog [2] family of languages, and to the guards in Delta-Prolog. Shared Prolog's preactivations are more general, but are harder to understand, and do not have a clear semantics (at least two semantics have been proposed in literature) [8]. The semantics of the conditional communication primitives of Delta Prolog [14] are synchronous and channel-based and therefore cannot be used as means for selection of messages. The remainder of this paper is organized as follows. After having speci ed the primitives of the extended Log language in section 2, section 3 de nes the operational semantics of the language in formal terms. Section 4 then illustrates the interest of the new primitives through the coding of an elevator system whereas section 5 describes their implementation. Finally, section 7 draws our conclusion.

The set of conditions is subsequently referred to as Scond. De nition 2 Blackboard primitives and goals are

inductively de ned as follows: i) the blackboard primitives are constructs of the form tellbb(bbn; bbt; bbg; C ), tellt(bbn; t; C ), tellp(bbn; p; C ), readbb(bbn; C ), readt(bbn; t; C ), readp(bbn; p; C ), getbb(bbn; C ), gett(bbn; t; C ), getp(bbn; p; C ), where t is a term, p is a goal, bbn is a ground term, bbt is a list of terms, bbg is a list of goals and C is a condition. tellbb, tellt, and tellp are use to create local blackboards, terms, and processes, respectively. read is used to check the presence of a blackboard, term or process, respectively, and get is used to remove it. ii) any atom and any blackboard primitive is a goal; iii) 2 is a goal, representing the empty goal; iv) if G1 and G2 are goals, then so are the sequential composition G1 ; G2 and the paralle composition G1 k G2 . The queries also called initial goals or igoal's, for short, are non-empty lists of goals [G1 ;


; Gm ] sharing no variables. The sets of goals and initial goals are subsequently referred to as Sgoal and Sigoal, respectively.

De nition 3 Log programs are composed of two

parts. A rst part consists in a set of pure Horn clauses (thereby containing no blackboard primitives) used to de ne atoms of conditions. They are noted as H ( B . The set of programs composed of these clauses is subsequently denoted as Scprog. A second part consists in a set of Horn clauses whose bodies are general goals and therefore can contain blackboard primitives. They are denoted as H G, to be distinguished from the former clauses. The set of programs is subseAs usual in logic programming, the (extended) quently denoted by Sprog and a program is typilanguage Log comprises denumerably in nite cally denoted by the pair (P ; P ) expressing the sets of variables, functions and predicates. They above two parts respectively. c b are referred to as Svar, Sfunct and Spred, respectively. The notions of term, atom, substituBackground and foreground processes are fortion, . . . are de ned therefrom as usual (see e.g. malized as follows. [13]). Their set is referred to as Sterm, Satom, Ssubst, . . . , respectively. We assume the reader De nition 4 Foreground and background procto be familiar with them and will not recall them esses are constructs of the form G@ and here. Rather, we now specify the concepts in- G@, respectively, where G is a goal and  is a substitution. A process is either a foreground duced by the blackboard extensions. process or a background process. It is denoted by De nition 1 Conditions are de ned as sequences an \(" arrow (as in ( G@) when there is no of atoms. The empty condition is denoted by 4. concern for its quali cation of being foreground or

2 The language

background. The set of processes is subsequently referred to as Sproc. The set of (possibly empty) multisets of background processes is subsequently referred to as Sbg. Convention 5 Given an igoal ig, we denote by ig the associated list of processes obtained by considering all the goals of ig as foreground processes and by associating each goal with the empty substitution .

3 Operational semantics

ementary parts, namely of atoms and of blackboard primitives. The transition system can thus be de ned by specifying the transition rules for the basic reductions of atoms and of blackboard primitives, and by giving the (classical) rules of composition for the compound goals. However, these last rules can be expressed directly in the former rules provided a suitable notion of contexts is introduced. Essentially, such a context determines, thanks to a place holder , which atoms or blackboard primitives can be reduced in any goal. The resulting goal is then obtained from the goal under consideration by replacing the reduced atoms and blackboard primitives by their corresponding subgoals according to their reduction.

Log are now formally described. The con gurations to be considered are described in the next section. The transition rules are presented in section 3.2 and a (formal) operational seman- De nition 6 The contexts are the functions intics is de ned in section 3.3 ductively de ned on the goals by the following rules. They are typically represented by the letter c, possibly subscripted. 3.1 Con gurations i)  is a context that maps any goal to itself. Classically, con gurations for languages are comFor any goal G, this application is subseposed of the current statement to be solved acquently referred to as [ G] . companied by a state, summing up the results ii) If c is a context and if G is a goal, then computed sofar. In a similar way, the con gura( c ; G), (c k G), (G k c) are contexts. Their tions considered here report the current contents applications are de ned as follows: for any of the blackboards. To that end, each blackboard 0, goal G is described by its name, its terms and its processes, with each process being described by the (c ; G)[[G0 ] = c[ G0 ] ; G goal it has to solve coupled with a substitution (c k G)[[G0 ] = c[ G0 ] k G summing up the values computed sofar for its (G k c)[[G0 ] = G k c[ G0 ] variables. The set of such con gurations is subsequently denoted by Sconf . The transition rules allow to pick some pro- In the above rules, we further state that the struccesses and blackboards inside multi-sets and sets, ture (Sgoal, ; , k ,2) is a bimonoid. Moreover, in respectively. For the ease of notation and to the following, we will simplify the goals resulting avoid any ambiguity, we will use the following from the application of contexts accordingly. two conventions. On the one hand, the notation m[ ] is intro- 3.2 Transition rules duced to denote a multiset where a place holder has been introduced at some place and the nota- The operational behavior of Log processes is tion m[e] is used to denote the multiset obtained formally de ned in Plotkin's style ([15]) by means from m[ ] by substituting the place holder by the of a transition relation, itself speci ed by rules of element e. Moreover, we will denote by m1 + m2 the form the multiset resulting from the union of the two CC ! CC  if Conditions; multisets m1 and m2 . On the other hand, we will use the notations that asserts the transition from the con gurafj e jg and fj e1 e2 jg to respectively denote a set tion CC to the con guration CC  whenever the (not necessarily reduced to one or two elements) Conditions hold. The precise de nition calls the in which the element e and the elements e1 ; e2 de nition of an auxiliary derivation relation forhave been selected. With respect to blackboards, malizing the classical SLD-derivation. It is reby convention, e1 and e2 will be considered to called here for completeness purposes. denote the same element in case they have the same name. De nition 7 De ne ` as the smallest relation Finally, it turns out that the behavior of com- of ScprogScondSsubst that satis es the folpound goals is determined by the behavior of el- lowing rules (E ) and (A).

(Ag )

fj hn; bt; m[( c[ A] @]i jg ! fj hn; bt; m[( c[ B ] @ ]i jg   if

(H B ) is a fresh renaming of a clause of Pb H and A unify with mgu Figure 1: Atom reduction

(Tb)

(Tt)

fj hn; bt; m[( c[ tellbb(bbn; bbt; bbp; C )]]@]i jg ! fj hn; bt; m[( c[ 2] @]i jg [ fhbbn; bbt0; bbp0ig 8 bbn is not the name of a blackboard appearing in the initial con guration > > > > < bbn is a ground term if > P ` C [] > the goals of bbp share no variables > > : bbt 0 and bbp0 are fresh renamings of bbt and bbp, respectively

9 > > > > = > > > > ;

fj hn; bt; m[( c[ tellt(bbn; t; C )]]@]i hbbn; bbt; bbpi jg ! fj hn; bt; m[( c[ 2] @]i hbbn; bbt + fug; bbpi jg 9 8 = < bbn is a ground term if : P ` C [] ; u is a fresh renaming of t

(Tp)

fj hn; bt; m[( c[ tellp(bbn; p; C )]]@]i hbbn; bbt; bbpi jg ! fj hn; bt; m[( c[ 2] @]i hbbn; bbt; bbp + f - q@g; i jg 8 9 < bbn is a ground term = if : P ` C [] ; q is a fresh renaming of p

Figure 2: Tell reductions (E) (A)

Pc ` 4 [] Pc ` (B; As) [] Pc ` A; As [ ]   ( B ) 2 Pc if (HH uni es with A with mgu 

De nition 8 De ne the transition relation ! as the smallest relation of Sconf  Sconf satisfying the rules (Ag ) to (Gp) of gures 1, 2, 3, and 4. As usual, for the ease of reading, the more suggestive notation Conf1 ! Conf2 is subsequently employed instead of ! (Conf1 ; Conf2 ).

Note that, thanks to the bimonoid structure imposed in de nition 6, it is implicitly understood in the rules (Ag ) to (Gp) that (2 ; G), (2 k G), (G k 2) are to be interpreted as G. It is also assumed there that the foreground and back-

ground quali cations are respected by the \(" arrow that is that, in any rule, all the occurrences of the \(" arrow have to be replaced either by the \ " arrow or by the \ -" arrow. A word on the meaning of the above rules is in order. Rule (Ag ) rephrases the usual reduction of an atom in our framework: an atom A is reduced to the body B of a uni able clause H B inside some process, this giving rise to the publication of the newly computed bindings

. Rule (Tb) describes the creation of a blackboard with the set of terms bbt and the foreground processes corresponding to the goals of bbp. Rules (Tt) and (Tp) explain the writing of terms and processes on the blackboard, respectively. Rules (Rb), (Rt), (Rp), (Gb), (Gt) and (Gp) describe the reading of blackboards, terms and processes with or without consumption. Particularly notice the renamings in the rules (Tb) to (Gp). They ensure that processes communi-

(Rb)

fj hn; bt; m[( c[ readbb(bbn; C )]]@]i hbbn; bbt; bbpi jg ! fj hn; bt; m[( c[ 2] @]i hbbn; bbt; bbpi jg   is a ground term if bbn P ` C []

(Rt)

fj hn; bt; m[( c[ readt(bbn; t; C )]]@]i hbbn; bbt; bbpi jg ! fj hn; bt; m[( c[ 2] @ ]i hbbn; bbt; bbpi jg 8 bbn is a ground term > > > < 9v 2 bbt : any fresh renaming v0 of v uni es with t if > is the mgu corresponding to the uni cation of t > fresh renaming of such a term v > > : P `andC of [some ]

(Rp)

9 > > > = > > > > ;

fj hn; bt; m[( c[ readp(bbn; p; C )]]@]i hbbn; bbt; bbpi jg ! fj hn; bt; m[( c[ 2] @ ]i hbbn; bbt; bbpi jg 8 bbn is a ground term > > > > < 9( - G) 2 bbp any fresh renaming G0 of G uni es with p if > is the mgu corresponding to the uni cation of p and of some fresh > of such a process - G > > : P `renaming C []

9 > > > > = > > > > ;

Figure 3: Read reductions cate only via the writing and reading of terms on tion. Termination status marks are appended to the blackboard and not implicitly by means of indicate success, real failure or suspension. shared variables. De nition 9 A con guration is called successfully terminated i all its foreground processes are of the form 2@ for some substitution . 3.3 Semantics We are now in a position to de ne an operational De nition 10 The set of words formed from are ended by semantics. In Log a successful computation is Ssubst and whose nite elements + (representing sucone of the termination marks  one for which all the foreground processes (of s ? all the blackboards) have been reduced to empty cess),  (representing suspension), and  (repreconjunctions, while some background processes senting failure) is referred to as Sohist. Its eleare possibly still running on some blackboards. ments are called operational histories. A rst natural property to be reported by the De nition 11 Given a con guration BB , we deoperational semantics thus consists of the substi- note by (BB ) the union of the substitutions astutions computed by those successful computa- sociated with the processes of BB . Note that betions. However, it is also interesting to account cause renaming is made before each operation on for failed computations, which may actually re- any blackboard and because processes are forced sult from three dierent reasons: in nite compu- to share no variables, such a union consists of a tations, the absence of suitable information on a well-de ned substitution. blackboard (suspension) and the absence of suit- De nition 12 De ne the operational semantics able clauses (real failure). The proposed operational semantics will also tackle these features. as the following function O : Sprog ! Sigoal ! To that end, it delivers for any initial goal not a P (Sohist) : for any P 2 Sprog, ig 2 Sigoal, set of substitutions but rather a set of so-called O(P )(ig) = computational histories de ned as words of sub- f(BB0):


:(BBm ):+ : (1; 2; 5; 6)g stitutions, each one summing up the substitu- [ f(BB0 ):


:(BBm ):? : (1; 3); not(5; 7)g tions associated with the processes of the black- [ f(BB0 ):


:(BBm ):s : (1; 3); not(5; 7)g boards at the considered moment of the execu- [ f(BB0 ):


:(BBm ):


: (4; 8)g

(Gb)

fj hn; bt; m[( c[ getbb(bbn; C )]]@]i hbbn; bbt; bbpi jg ! fj hn; bt; m[( c[ 2] @]i jg   term if Pbbn `is aCground []

(Gt)

fj hn; bt; m[( c[ gett(bbn; t; C )]]@]i hbbn; bbt; bbpi jg ! fj hn; bt; m[( c[ 2] @ ]i hbbn; bbt0; bbpi jg 8 bbn is a ground term > > > > 9v 2 bbt : any fresh renaming v0 of v uni es with t > > > < u is such a term v in bbt if > is the mgu corresponding to the uni cation of t > and of some fresh renaming of u > > 0 is bbt where u has been removed > bbt > > : P ` C []

(Gp)

9 > > > > > > > = > > > > > > > ;

fj hn; bt; m[( c[ getp(bbn; p; C )]]@]i hbbn; bbt; bbpi jg ! fj hn; bt; m[( c[ 2] @ ]i hbbn; bbt; bbp0i jg 8 bbn is a ground term > > > > > 9( - G) 2 bbp : any fresh renaming G0 of G uni es with p > > < - G00 is such a process - G in bbp if > is the mgu corresponding to the uni cation of p and of some fresh > renaming of G00 > > 0 > where the process corresponding to - G00 has been removed > > : Pbbp `is bbp C []

9 > > > > > > > = > > > > > > > ;

Figure 4: Get reductions The careful reader will have noticed that suswhere (1), . . . , (8) stand for the following condipending read and get primitives have only been tions: treated. However, it is easy to modify the above (1) BB0 = fhinit; ;; ig; ig; (where init in the transition rules to account for non suspending but failing versions of these primitives. Indeed, it name of the initial blackboard) is sucient for that purpose to introduce an ex(2) BB0 !


! BBm plicit fail con guration and to make transitions to this con guration for non-suspending primi(3) BB0 !


! BBm 6! tives faced to a lack of blackboards, terms or processes. In the next section, non-suspending (non(4) BB0 !


! BBm !


; blocking) primitives will be suxed with nb. (5) BBm is successfully terminated,

(6) BBi is not successfully terminated for 1i 1 NextFloor is Floor 1.

;

+

;

?

;

?

;

+

?

;

;

;

+

main putbb(building,[ ],[person(1),person(2),person(4),person(7)], ) putbb(elevator1,[ ],[elevator(1,up,elevator1)], ) putbb(elevator2,[ ],[elevator(1,up,elevator2)], ).


k


higher(X,Y) lower(X,Y)

> Y. < Y.

X X

Figure 5: Sample program


k

?

(in(CurrentFloor,Direction)) of users of the elevators, and one blackboard per elevator where the nal destinations (out(Destination)) of the people in the elevator are stored. The elevator and person processes are created from recursive predicates that keep a state composed of the current oor and the current direction for the elevator processes, and the current

oor for the person processes. The person process is almost trivial. Depending on his destination, the user pushes the up or down button, waits for the door of one of the elevators (Name) to open, enters the elevator, puts his destination oor on the elevator blackboard, and then waits for the door to open on the destination oor. The elevator synchronizes with the users by putting the term door open/2 on the global blackboard building. The elevator process is slightly more sophisticated. The main idea is that the elevator lets somebody in, moves to the destination oor, and on its way picks up everybody who wants to move in the same direction. The predicate muststop checks whether the elevator should stop on a particular oor. Per

oor, it therefore checks the local elevator blackboard to see whether somebody wants to leave, and also checks the global blackboard building to see whether somebody wants to join in the same direction. The predicate cleanup is used to remove all the redundant requests for the same

oor (two people pushing the same button, and so on). When the elevator must stop, it opens the doors, waits a few seconds, and then closes the doors again, and calls itself recursively. If somebody has pushed the button once more, the doors might open again. Otherwise, the elevator will move to the next oor. The selection of the next oor is based on priorities. First, it delivers people with a destination in the current direction, then it delivers people that are moving in the opposite direction. If there are no people in the elevator, it moves to the person who is waiting the longest time for the elevator, and if nobody is waiting, the elevator moves to the rst oor. Any number of elevators can be added to the system. The system is not energy-conscious but competes. So, if all the elevators are idle, and somebody needs an elevator, they will all take o, and as soon as the rst arrives, the other elevators will stop, and return to their home position, or pick up somebody else. The resulting code is shown in gure 5. The elevator system can be made more so-

phisticated by adding additional synchronization to the program. Other elevator commands such as emergency stop, keep the doors open, and so on can be implemented in a couple of lines of code. In this example, the conditional blackboard operations are essential to express the fact that the elevator is only looking for pending requests in the direction in which it is currently moving. If conditions were not available, it would be dicult to elegantly and correctly express this restriction because uni cation is not powerful enough to select the right term. The local blackboards are essential to make sure that elevators have their own state, and are not in uenced by each other. Of course, the name of the elevators could be coded into the terms on a global blackboard, but this solution would be less elegant, and harder to implement eciently. As a nal syntactical point, we have suxed by b and nb the read/get primitives respectively blocking and non blocking on the non-availability of resources.

5 Implementation The extended Log framework has been implemented in the Multi-BinProlog language. This language features both blocking and non-blocking get and read primitives, tell, and the dynamic creation of processes and blackboards. Due to implementation limitations, some of them are implemented in a slightly dierent way from what is announced in the theoretical model, namely processes are not killed by uni cation (as in getp), but by specifying a kind of process identi cation. The blackboards are implemented as passive data structures, not as active processes. For a comprehensive description of the implementation of such a passive blackboard, we refer to [5]. The essence of it is that the blackboard is just a data structure that is manipulated by the blackboard communication routines. In order to minimize the amount of computations, uni cations on the blackboard are never executed more than once. A blackboard consists of two lists: a list of terms, and a list of suspended processes. List elements are characterized by Prolog terms. A get operation scans the list of terms in chronological order and tries to nd a term that uni es with its argument. When a uni able term is found and if the get operation is destructive, the term is removed from the list. If no unifying term is found, the processes that has issued the get operation puts itself at the end of the list of suspended

processes and suspends after having stored its argument. A put operation is responsible for checking whether there are suspended processes waiting for its argument. It therefore checks the stored arguments of the get operations in chronological order and resumes the oldest process it can unify with. If the unifying get operation is nondestructive, the process goes on until a destructive get operation is found. If no get operation is found, the argument of the put-operation is stored in the term list. This is basically the implementation method for the kernel language. The modi cations needed for the conditions are minimal. After we have found a term that uni es, we also have to check the condition. Only if the condition succeeds, we can successfully continue. When no suitable term is found, the process must suspend. In this case, we must not only store the argument, but also the condition. A put operations that searches for a unifying get operation will not only have to unify with the stored argument, but will also have to check the condition. Here it becomes clear that the condition must not contain side eects. Indeed, as the condition is no longer executed by the get operations, but by the put-operations, the side eect would occur on places where one does not expect them. For the implementation of the global and local blackboards, we have made use of a shared memory segment allocated as a Unix system V IPC service. The memory segment is managed and made available to the processes by an ef cient memory management system based on a buddy algorithm. This global memory pool is subsequently used to allocate blackboards. A blackboard is essentially a block of shared memory. Internally, the same memory management system is used to manage the memory of each individual blackboard. Initially, the blackboard size is 4 kB. If needed, additional memory is automatically allocated from the global shared memory pool.

read guard), and a Prolog goal that must evaluate true. Only after the whole guard evaluates successfully, the method commits to it, and the other competing guards are canceled. Although this mechanism is very powerful, it has never been treated formally, and as is pointed out by Gaspari in [8], the semantics has changed from one version of the language to another. Our approach is simpler, can be treated semantically in an elegant way, and provides most of the functionality of the Shared Prolog language at a higher eciency. Other blackboard-based languages do not have provisions for conditions. The solution proposed by Sutclie in [16] is to let the condition evaluate by the sender instead of the receiver and adding the result of the evaluation as an extra argument to the term to be communicated. It is clear that this creates a severe overhead in case there are many dierent kinds of conditions to be evaluated in a system. Furthermore, in applications where not all the conditions are known at compile time, this technique cannot be used. Delta-Prolog [14] is a channel-based language that supports guards on the sender side, as well as on the receiver side. The guards are mainly use in combination with the so-called choice goals, in which the elements, also called the alternatives, contain the communication primitives. Furthermore, the conditional primitives are synchronous. In our approach, we are not con ned to a particular syntactical construct, nor to synchronous communication. The conditional blackboard primitives are completely unconstrained. Linda [9] and Polis Prolog [3] support multiple tuple spaces in a similar we as in Log. However, our framework is more integrated as we use tell/read/get primitives not only to manipulate data, but also to manipulate processes and blackboards.

7 Conclusion This paper has build upon previous work by the authors ([5, 11]) to propose new mechanisms that are currently lacking but are of a practical necessity. On the one hand, local blackboards are introduced to provide processes with private memories as well as to allow communication between some processes to take place locally as opposed to globally. On the other hand, conditional operations are proposed in order to select data on the blackboard in a richer way than what can be achieved by uni cation only. The interest of the new primitives has been illustrated through the coding of an elevator sys-

6 Comparison with related work There are not so many languages that support conditions on communication operations. The most notable one is certainly Shared Prolog [2] that has a more general mechanism based on Dijkstra's guards. A method can have multiple competing guards containing a set of terms that should be removed from the blackboard (the so-called an in guard), a set of terms that should be available on the blackboard (the so-called a

tem. They have there been proved to be simple yet expressive enough. Their implementation has also been discussed and a (formal) operational semantics has been proposed.

[9]

Acknowledgment

The authors are supported by the Belgian Na- [10] tional Fund for Scienti c Research as senior research assistants. They are grateful to B. Le Charlier and J. Van Campenhout for their support and advice. Also, this work has greatly bene ted from discussions with P. Tarau, M. Wise, [11] A. Brogi, and P. Ciancarini.

References

[12]

[1] S. Ahuja, N. Carriero, and D. Gelernter. Linda and friends. IEEE Computer, 19(8):26{34, August 1986. [2] Antonio Brogi and Paolo Ciancarini. The Concurrent Language Shared Prolog. ACM Transactions on Programming Languages and Systems, 13(1):99{123, January 1991.

[3] P. Ciancarini. Parallel Logic Programming [13] using the Linda model of Computation. In Goos and Hartmanis [10], pages 110{125. [14] [4] K. De Bosschere. Multi-Prolog: een Bordgebaseerde Parallelle Logische Programmeertaal. PhD thesis, Faculteit van de Toegepaste Wetenschappen, Universiteit Gent, September 1992. [15] [5] K. De Bosschere and J.-M. Jacquet. MultiProlog: De nition, Operational Semantics and Implementation. In D.S. Warren, editor, Proceedings of the ICLP'93 conference, [16] pages 299{313, Budapest, Hungary, June 1993. The MIT Press. [6] K. De Bosschere, J.M. Jacquet, and A. Brogi, editors. Proceedings of the ICLP'94 Post-Conference Workshop on [17] Process-Based Parallel Logic Programming, S. Margherita, Italy, June 1994. [7] K. De Bosschere, J.M. Jacquet, and P. Tarau, editors. Proceedings of the ICLP'93 Post-Conference Workshop on BlackboardBased Logic Programming, Budapest, Hungary, June 1993. [8] M. Gaspari. A shared-dataspace language and its compilation. Technical Report

UBLCS-94-5, University of Bologna, March 1994. David Gelernter. Multiple Tuple Spaces in Linda. In Proceedings of the PARLE'89 Conference, volume 365 of Lecture notes on Computer Science, pages 20{27, 1989. G. Goos and J. Hartmanis, editors. Proceedings of Research Directions in High-Level Parallel Programming Languages. Springer Verlag, Mont Saint Michel, France, June 1991. J.-M. Jacquet and K. De Bosschere. On the Semantics of Log. Future Generation Computer Systems, 10:93{135, April 1994. T. Lindholm and R. A. O'Keefe. Ecient Implementation of a Defensible Semantics for Dynamic prolog code. In Jean-Louis Lassez, editor, Proceedings of the Fourth International Conference on Logic Programming, MIT Press Series in Logic Programming, pages 21{39, Cambridge, Massachusetts London, England, 1987. MIT Press. J.W. Lloyd. Foundations of Logic Programming. Springer-Verlag, second edition, 1987. L.M. Pereira, L.F. Monteiro, J.C. Cunha, and Aparcio. Concurrency and Communication in Delta-Prolog. In The Design and Application of Parallel Digital Processors, volume 298, pages 94{104. IEEE, 1988. G. Plotkin. A Structured Approach to Operational Semantics. Technical Report DAIMI FN-19, Computer Science Department, Aarhus University, 1981. G. Sutclie, and J. Pinakis. Prolog-D-Linda: An Embedding of Linda in SICStus Prolog. Technical Report 91/7, Department of Computer Science, University of Western Australia, 1991. M.J. Wise, D.G. Jones, and T. Hintz. PMS-Prolog: A Distributed Coarse-grainparallel Prolog with Processes, Modules and Streams. In Peter Kacsuk and Michael J. Wise, editors, Implementations of Distributed Prolog, Series in Parallel Computing, pages 379{403. Wiley, Chichester, 1992.