Decoupled execution of synchronous coordination models via behavioural automata

M.R. Mousavi and A. Ra vara: FOCLASA 2011 EPTCS 58, 2011, pp. 65–79, doi:10.4204/EPTCS.58.5 c  J. Proenc ¸ a, D. Clarke, E. de V ink & F . Arbab This work is licensed under the Creativ e Commons Attribution License. Decoupled execution of synchr onous coordination models via beha vioural automata Jos ´ e Proenc ¸ a Dav e Clarke IBBT -DistriNet, KUL, Leuven, Belgium { jose.proenca,dave.clarke } @cs.kuleuven.be Erik de V ink TUE, Eindhov en, The Netherlands evink@win.tue.nl Farhad Arbab CWI, Amsterdam, The Netherlands farhad.arbab@cwi.nl Synchronous coordination systems allow the exchange of data by logically indivisible actions in volv- ing all coordinated entities. This paper introduces behavioural automata, a logically synchronous coordination model based on the Reo coordination language, which focuses on relev ant aspects for the concurrent e volution of these systems. W e show ho w our automata model encodes the Reo and Linda coordination models and how it introduces an explicit predicate that captures the concurrent ev olution, distinguishing local from global actions, and lifting the need of most synchronous models to in volve all entities at each coordination step, pa ving the way to more scalable implementations. 1 Intr oduction Synchronous constructs in languages such as Reo [1] and Esterel [7] are useful for programming reactiv e systems, though in general their realisations for coordinating distributed systems become problematic. For example, it is not clear ho w to efficiently implement the high degrees of synchronisation expressed by Reo in a distributed context. T o remedy this situation, the GALS (globally asynchronous, locally synchronous) model [9, 13] has been adopted, whereby local computation is synchronous and commu- nication between dif ferent machines is asynchronous. Our work contrib utes to the field of coordination, in particular to the Reo coordination language, by incorporating the same ideas behind GALS in our approach to ex ecute synchronisation models. More specifically , we introduce behavioural automata to model synchronous coordination, inspired in Reo [6]. Each step taken by an automata corresponds to a round of “synchronous” actions performed by the coordination layer , where data flow atomically through a set of points of the coordinated system. The main motiv ation behind behavioural automata is to describe the synchronous semantics underlying Dreams [18], a prototype distributed framework briefly discussed in § 5.2 that stands out by the decoupled ex ecution of Reo -like coordination models in a concurrent setting. Dreams improves the performance and scalability of pre vious attempts to implement similar coordination models. Our automata model captures exactly the features implemented by Dreams . Behavioural automata assume certain properties over their labels, such as the existence of a compo- sition operator, and use a predicate associated to each of its states that is needed to guide the composition of automata. Different choices for the composition operator of labels and the predicates yield different coordination semantics. W e instantiate our automata with the semantics for Reo and Linda coordination models, but other semantic models can also be captured by our automata [18]. W e do not instantiate behavioural automata with Esterel as the propagation of synchrony in this language differs from our dataflo w-driv en approach [3]. Summarising, the main contributions of this paper are: • a unified automata model that captures dataflow-oriented synchronous coordination models; 66 Decoupled execution of synchronous coordination models • the introduction of concurr ency pr edicates , increasing the expressiv eness of the model when deal- ing with composed automata; and • the decoupling of execution of a distrib uted implementation based on our automata model, by av oiding unnecessary synchronisation of actions whenever possible. Each behavioural automaton has a concurrenty predicate that indicates, for each state, which labels of other automata require synchronisation. When composing tw o automata, labels must be either composed in a pairwise fashion, or they can be performed independently when the concurrency predicate does not require synchronisation. W e exploit ho w to use concurrency predicates to distinguish transitions of a composed automaton that originate from all intermediate automata, or from only a subset of them. W e also illustrate ho w to obtain more complex notions of coordination by increasing the comple xity of concurrency predicates. This paper is organised as follows. W e introduce behavioural automata in § 2. W e then encode Reo as behavioural automata in § 3 and Linda as behavioural automata in § 4. In § 5 we motiv ate the need for concurrency predicates, both from a theoretical and practical perspecti ves. W e conclude in § 6. 2 A stepwise coordination model In this section we present an automata model, dubbed behavioural automata . This model represents our vie w of a dataflow-dri ven coordination system, following the cate gorisation of Arbab [3]. Each transition in an automaton represents the atomic ex ecution of a number of actions by the coordination system. W e describe the behaviour of a system by the composition of the behaviour of its sub-systems running concurrently , each with its own automaton. Furthermore, we allo w the data values exchanged ov er the coordination layer to influence the choice of ho w components communicate with each other as well. W e borro w ideas from the T ile model [14, 4], distinguishing ev olution in time (execution of the coordination system) and ev olution in space (composition of coordination systems). Behavioural automata can be built by composing more primiti ve behavioural automata, and each transition of an automaton denotes a round of the coordination process, where data flo w atomically through zero or more ports of the system. W e use behavioural automata to give semantics to Reo , based on the constraint automata model [6], and to (distributed) Linda [15]. Each label of an automaton describes which ports should have dataflo w , and what data should be flowing in each port. W e write P to denote a global set of ports, L [ P ] to denote the set of all labels over the ports P ⊆ P , and D to denote a global set of data v alues. W e associate a predicate ov er labels to each state q of an automaton, referred to as C ( q ) . These predicates are used to guide the composition of behavioural automata. Definition 1 (Beha vioural automata) A behavioural automaton of a system over a set of ports P ⊆ P is a labelled transition system h Q , L [ P ] , → , C i , where L [ P ] is the set of labels over P, → ⊆ Q × L [ P ] × Q is the tr ansition r elation, and C : Q → 2 L [ P ] is a pr edicate over states and labels, called concurrency predicate , r egar ded as a function that maps states to sets of labels. The ke y ingredients of behavioural automata are atomic steps and concurr ency predicates . Each label of a behavioural automaton has an associated atomic step, which captures aspects such as the ports that hav e flo w and the data flowing through them, and concurrency predicate describe, for each state, which labels from other automata running concurrently require synchronisation. Example 1 (Alternating coordinator) W e pr esent the alternating coordinator (AC) in F igur e 1. It r e- ceives data fr om two data writers W 1 and W 2 , and sends data to a reader R. The components W 1 , W 2 J. Proenc ¸ a, D. Clarke, E. de V ink & F . Arbab 67 W 1 W 2 A C R a b c q 0 q 1 ( v ) C ( q 0 ) C ( q 1 ( v )) s 1 ( v , w ) s 2 ( v ) s 1 ( v , w ) = read w from a , read v from b , and write w to c s 2 ( v ) = write v to c Figure 1: Alternating coordinator (left), and its behavioural automaton (right). and R are connected, respectively , to the ports a, b and c of the alternating coor dinator . The alternat- ing coordinator describes how data can flow between the components, and coor dination is specified by the behavioural automaton depicted on the right side of F igur e 1. Each transition of this automaton r epresents a possible step in time of the coor dinator A C , describing how the ports a, b, and c can have dataflow . Initially , the coordinator is in state q 0 , wher e the only possible action is r eading a value w fr om W 1 thr ough a and sending it to the reader R thr ough c, while r eading and buffering a value v sent by W 2 thr ough b. Note that if only one of the writers can pr oduce data, the step cannot be taken, and the system cannot e volve. In the ne xt state, q 1 , the only possible step is to send the value v to the r eader R, returning to state q 0 . The arr ows between states r epr esent the transition r elation → . In both states ther e is the possibility of allowing the concurr ent execution of other automata, pr ovided that this e xecution does not interfer e with the curr ent behaviour . The conditions of when other automata can execute concurr ently ar e captured by the concurr ency pr edicate C , depicted by squiggly arr ows ( ) fr om each state. 2.1 Labels, atomic steps and concurrent pr edicates Labels ov er a set of ports P are elements from a set L [ P ] with some properties required for composition, which we will introduce later . Furthermore, a label  ∈ L [ P ] can be restricted to a smaller set of ports P 0 ⊆ P , written  ( P 0 ) . W e require each label  ∈ L [ P ] to have an associated description of where and which data flo w in the connector , written as α (  ) , and captured by the notion of atomic step . Definition 2 (Atomic step) An atomic step over the alphabet P ⊆ P is a tuple h P , F , IP , OP , data i wher e: F ⊆ P I P ⊆ F OP ⊆ F I P ∩ OP = / 0 and d at a : ( IP ∪ OP ) → D . W e write AS [ P ] to denote the set of all atomic steps over the ports in P . P is a set of ports in the scope of the atomic step. The flo w set F is the set of ports that synchr onise , i.e., that have data flowing in the same atomic step. The sets IP and OP represent the input and output ports of the atomic step that have dataflo w , and whose v alues are considered to be rele vant when performing a step. Ports in F but not in IP or OP are ports with dataflo w , but whose data values are not relev ant, that is, they are used only for imposing synchronisation constraints. The data v alues that flow through the relev ant ports are gi ven by the data function data . W e distinguish IP and OP to capture data dependencies. Concurrency predicates are used to compose behavioural automata. When composing two automata a 1 and a 2 , if a 1 has ports P 1 , has the concurrency predicate C 1 , and is in state q 1 , then  ( P 1 ) 2 ∈ C 1 ( q 1 ) means that a 2 can perform  2 only when composed with a transition from a 1 , otherwise a 2 can perform  2 without requiring a 1 to perform a transition. 1 When clear from context, we omit the restriction and write  2 ∈ C 1 ( q 1 ) instead of  ( P 1 ) 2 ∈ C 1 ( q 1 ) . W e gi ve a possible definition for concurrency predicates based 1 W e present a variation of the original definition of concurrency predicates [18] to make the decision of belonging to a concurrent predicate more local. 68 Decoupled execution of synchronous coordination models solely on the set of known ports. 2 Gi ven a connector with known ports P 0 , the concurrency predicate of e very state is gi ven by the predicate cp ( P 0 ) = {  | α (  ) = h P , F , IP , OP , data i , P 0 ∩ F 6 = / 0 } . (1) Example 2 W e define the atomic steps and concurr ency pr edicates fr om Example 1 as follows. α ( s 1 ( v , w )) = h P , abc , ab , c , { a , b , c 7→ w , v , w } i C ( q 1 ( v )) = cp ( P ) α ( s 2 ( v )) = h P , c , / 0 , c , { c 7→ v } i C ( q 0 ) = cp ( P ) F or simplicity , we write a 1 . . . a n instead of { a 1 , . . . , a n } when the intended notion of set is clear fr om the context. The alphabet P is { a , b , c } , and the concurrency pr edicates allow only steps wher e none of the known ports has flow . 2.2 Composition of beha vioural automata T o compose beha vioural automata we require labels to be elements of a partial monoid h L , ⊗ i , that is, (1) there must be a commutati ve operator ⊗ : L 2  L for labels, and (2) the composition of two labels can be undefined, meaning that they are incompatible. For technical con venience, we require ⊗ to be associati ve and to hav e an identity element. The atomic step h P , F , IP , OP , data i of a composed label  1 ⊗  2 must obey the follo wing conditions, where, for every label  1 or  2 , α (  i ) = h P i , F i , IP i , OP i , data i i . P ⊆ P 1 ∪ P 2 IP ⊆ ( IP 1 ∪ IP 2 ) \ ( OP 1 ∪ OP 2 ) data 1  data 2 F ⊆ F 1 ∪ F 2 OP ⊆ OP 1 ∪ OP 2 data = data 1 ∪ data 2 The atomic step of a label  is represented by α (  ) . The notation m 1  m 2 represents that the values of the common domain of mappings m 1 and m 2 match. The requirements on the sets IP and OP reflect that when composing two atomic steps, the input ports that have an associated output port are no longer treated as input ports (since the dependencies have been met), and the output ports are combined. The intuition behind the remov al of input ports that match an output port is the preservation of the semantics of Reo : multiple connections to an output port replicate data, but multiple connections to input data require the merging of data from a single source. W e now describe the composition of behavioural automata based on the operator ⊗ and on concur- rency predicates. This composition mimics the composition of existing Reo models [6, 11, 8]. Definition 3 (Product of beha vioural automata) The pr oduct of two behavioural automata b 1 = h Q 1 , L [ P 1 ] , → 1 , C 1 i and b 2 = h Q 2 , L [ P 2 ] , → 2 , C 2 i , denoted by b 1   b 2 , is the behavioural automaton h Q 1 × Q 2 , L [ P 1 ∪ P 2 ] , → , C i , wher e → and C are defined as follows: → = {  ( p , q ) , , ( p 0 , q 0 )  | p  1 − → 1 p 0 , q  2 − → 2 q 0 ,  =  1 ⊗  2 ,  6 = ⊥} ∪ (2) {  ( p , q ) , , ( p 0 , q )  | p  − → 1 p 0 ,  ( P 2 ) / ∈ C 2 ( q ) } ∪ {  ( p , q ) , , ( p , q 0 )  | q  − → 2 q 0 ,  ( P 1 ) / ∈ C 1 ( p ) } (3) C ( p , q ) = C 1 ( p ) ∪ C 2 ( q ) for p ∈ Q 1 , q ∈ Q 2 . (4) Case (3) cov ers the situation where one of the beha vioural automata performs a step admitted by the concurrency predicate of the other , and case (4) defines the composition of two concurrency predicates. In practice, our frame work based on beha vioural automata, briefly described in § 5.2, uses a symbolic representation for data values assuming that variables can be instantiated after selecting the transition. This suggests the use of a late-semantics for data-dependencies. Our approach to compose labels resem- bles Milner’ s synchronous product in SCCS [17], with the main difference that the product of behavioural automata do not require the all labels to be synchronised. The product of labels from two behavioural automata can be undefined, and labels can av oid synchronisation when the concurrenc y predicate holds. 2 Other semantic models may require more complex concurrency predicates. For example, the concurrency predicates for the Reo automata model [8] depend on the current state (Section 3.6.2 of [18]). J. Proenc ¸ a, D. Clarke, E. de V ink & F . Arbab 69 empty full ( v ) full ( w ) cp ( a , a 0 ) cp ( a , a 0 ) cp ( a , a 0 ) s 3 ( v ) s 3 ( w ) s 4 ( v ) s 4 ( w ) s 3 ( w ) s 3 ( v ) s 3 ( v ) s 3 ( w ) where: α ( s 3 ( v )) = h aa 0 , a 0 , a 0 , / 0 , { a 0 7→ v }i α ( s 4 ( v )) = h aa 0 , a , / 0 , a , { a 7→ v }i Figure 2: Behavioural automaton of the lossy-FIFO connector . LF a 0 a   A C a b c = LF   A C a 0 b c Figure 3: The sink and source ports of LF , A C , and their composition. 2.3 Example: lossy alternator Recall the beha vioural automaton A C of the alternating coordinator , illustrated in Figure 1. Data is recei ved always via ports a and b simultaneously , and sent via port c , alternating the values receiv ed from a and b . W e no w imagine the follo wing scenario: the data on a becomes av ailable always at a much faster rate than data on b . T o adapt our alternating coordinator to this new scenario, we introduce a lossy-FIFO connector LF [1] and compose it with the alternating coordinator, yielding LF   A C . Recall the definition of cp : P → L [ P ] gi ven by Equation (1). The behavioural automaton for the lossy-FIFO connector is depicted in Figure 2, and its atomic steps range ov er the ports { a , a 0 } , where a 0 is an input port and a is an output port. W e depict the interface of both of these connectors on left hand side of Figure 3. After combining the behavioural automata of the two connectors, they become connected via their shared port a . The ne w v ariation of the alternating coordinator can then be connected to data producers and consumers by using the ports a 0 , b and c , as depicted at the right hand side of Figure 3. Intuiti vely , the lossy-FIFO connector receiv es data a 0 and buf fers its value before sending it through a . When the buf fer is full data receiv ed from a 0 replaces the content of the buf fer . The connector resulting from the composition LF   A C is formalised in T able 1 and in Figure 4. The flow sets of the labels s 1 ( v , w ) , s 2 ( v ) , s 3 ( v ) and s 4 ( v ) are, respectiv ely , abc , c , a 0 , and a 0 a , and the set of known ports is P = { a 0 , a , b , c } . Let C LF and C A C be the concurrency predicates of LF and A C . The concurrency predicate C LF   A C for LF   A C results from the union of the predicates of the states of each behavioural automaton, and corresponds precisely to the concurrency predicate that maps each state to cp ( a 0 , a , b , c ) . The name of each state in LF   A C is obtained by pairing names of a state from LF and a state from A C . Some states and transitions are coloured in gre y with their labels omitted to av oid cluttering the diagram. From the diagram it is clear that some transitions originate only from the LF or the A C connector, while others result from the composition via the operator ⊗ . The transitions s 2 ( v ) and s 3 ( w ) can be per- 70 Decoupled execution of synchronous coordination models ⊗ s 1 ( u , v ) s 2 ( w ) s 3 ( y ) ⊥ h P , a 0 c , a 0 , c , { a 0 , c 7→ y , w } i s 4 ( z ) ⊥ (for z 6 = v ) ⊥ s 4 ( v ) h P , abc , ab , c , { a , b , c 7→ v , u , v } i ⊥ LF C LF ( empty ) C LF ( full ( v 0 )) s 1 ( v , w ) true true s 2 ( v ) false false A C C A C ( q 0 ) C A C ( q 1 ( v 0 )) s 3 ( v ) false false s 4 ( v ) true true T able 1: Atomic steps of the composition of labels from LF and A C (left), and verification of the concur - rency predicate for each label (right). empty , q 0 empty , q 1 ( w ) full ( v ) , q 0 full ( v ) , q 1 ( w ) cp ( a 0 , a , b , c ) cp ( a 0 , a , b , c ) cp ( a 0 , a , b , c ) cp ( a 0 , a , b , c ) full ( v 0 ) , q 0 full ( v 0 ) , q 1 ( w ) s 3 ( v ) s 3 ( v ) s 1 ( w , v ) ⊗ s 4 ( v ) s 2 ( w ) s 2 ( w ) ⊗ s 3 ( v ) s 3 ( v ) s 3 ( v ) s 2 ( w ) s 2 ( w ) ⊗ s 3 ( v ) Figure 4: Behavioural automaton for the composition of LF and A C . formed simultaneously or interleaved; simultaneously because s 2 ( v ) ⊗ s 3 ( w ) is defined, and interleav ed because C LF ne ver contains s 2 ( v ) and C AC ne ver contains s 3 ( w ) . The possible ex ecution scenarios of these atomic steps follow our intuition that steps ‘approv ed’ by concurrency predicates can be performed independently . The steps s 1 ( u , v ) and s 4 ( w ) can be taken only when composed. 2.4 Locality W e introduce the notion of locality as a property of behavioural automata that guarantees the absence of certain labels in the concurrency predicates of independent beha vioural automata, that is, in automata without shared ports. Definition 4 (Locality of beha vioural automata) A behavioural automaton b = h Q , L [ P ] , → , C i obe ys the locality property if, for any port set P 0 such that P ∩ P 0 = / 0 , ∀  ∈ L [ P 0 ] · ∀ q ∈ Q ·  ( P ) / ∈ C ( q ) . Any two behavioural automata with disjoint port sets that obey the locality property can therefore e volv e concurrently in an interleaved fashion. Let b = b 1   b 2 be a behavioural automaton and  a label from b 1 . W e say  is a local step of b if ( q 1 , q 2 )  − → ( q 0 1 , q 0 2 ) is a transition of b and either q 1  − → 1 q 0 1 , q 2 = q 0 2 , and  ∈ C 2 ( q 2 ) ; or q 2  − → 2 q 0 2 , q 1 = q 0 1 , and  ∈ C 1 ( q 1 ) . In the behavioural automaton ex emplified in Figure 4, the local steps are exactly the transitions labelled by the steps s 2 ( w ) and s 3 ( v ) . J. Proenc ¸ a, D. Clarke, E. de V ink & F . Arbab 71 Proposition 1 Let b = b 1   b 2   b 3 be a behavioural automaton wher e b i = h Q i , L [ P i ] , → i , C i i , for i ∈ 1 .. 3 , and assume the locality pr operty fr om Definition 4 holds for b 1 , b 2 and b 3 . Suppose P 1 ∩ P 3 = / 0 . Then, for any step  ( P 1 ) 1 ∈ L [ P 1 ] performed by b 1 and q 2 ∈ Q 2 , if  ( P 2 ) 1 / ∈ C 2 ( q 2 ) then  1 is a local step of b. Pr oof. Observe that   is associativ e, up to the state names, because the composition of labels ⊗ is associati ve. From P 1 ∩ P 3 = / 0,  1 ∈ L [ P 1 ] , and from the locality property in Definition 4 we conclude that ∀ q ∈ Q 3 ·  ( P 3 ) 1 / ∈ C 3 ( q ) . Therefore, for any state q 3 ∈ Q 3 and for a state q 2 ∈ Q 2 such that  ( P 2 ) 1 / ∈ C 2 ( q 2 ) , we have that  ( P 2 ) 1 / ∈ C 2 ( q 2 ) ∪ C 3 ( q 3 ) . W e conclude that  ( P 2 ∪ P 3 ) 1 / ∈ C 0 , where C 0 is the concurrency predicate of b 2   b 3 , hence a local step of b . 2 If the locality property holds for each behavioural automata b i in a composed system b = b 1   · · ·   b n , then, using Proposition 1, we can infer wether atomic steps from b i are local ste ps of b based only on the concurrency predicates of its neighbour automata , i.e., the automata that share ports with b i . 2.5 Concrete beha vioural automata A behavioural automaton is an abstraction of concrete coordination models that focuses on aspects rel- e vant to the execution of the coordination model. As we will argue, Reo and Linda can be cast in our frame work of beha vioural automata. Therefore, both Reo and Linda coordination models can be seen as specific instances of the stepwise model described abov e. For a concrete coordination model to fit into the stepwise model, we need to define: (1) labels in the concrete model; (2) the encoding α of labels into atomic steps; (3) composition of labels; and (4) concurrency predicates. W e start by encoding the constraint automata semantics of Reo as behavioural automata. Later , because of its relev ance in the coordination community as one of the first coordination languages, we also encode Linda as a behavioural automaton. Other coordination models hav e also been encoded as behavioural automata in Proenc ¸ a’ s Ph.D. thesis [18]. 3 Encoding Reo Reo [1, 2] is presented as a channel-based coordination language wherein component connectors are compositionally built out of an open set of primitive connectors , also called primitiv es. Channels are primiti ves with two ends. Existing tools for Reo include an editor , an animation generator , model check- ers, editors of Reo -specific automata, QoS modelling and analysis tools, and a code generator [5, 16]. The behaviour of each primitiv e depends upon its current state. 3 The semantics of a connector is described as a collection of possible steps for each state, and we call the change of state of the connector triggered by one of these steps a r ound . At each round some of the ends of a connector are synchronised, i.e., only certain combinations of synchronous dataflow through its ends are possible. Dataflo w on a primiti ve’ s end occurs when a single datum is passed through that end. W ithin any round dataflow may occur on some number of ends. Communication with a primitive connector occurs through its ports, called ends . Primitiv es consume data through their sour ce ends , and produce data through their sink ends . Connectors are formed by plugging the ends of primitiv es together in a one-to-one fashion to form nodes . A node is a logical place consisting of a sink end, a source end, or both a sink and a source end. 4 W e now gi ve an informal description of some of the most commonly used Reo primiti ves. Note that, for all of these primitiv es, no dataflo w is one of the behavioural possibilities. The Sync channel 3 Note that most Reo primitiv es presented here hav e a single state. 4 Generalised nodes with multiple sink and source ends can be defined by combining binary mergers and replicators [6, 11]. 72 Decoupled execution of synchronous coordination models ( ) sends data synchronously from its source to its sink end. The LossySync channel ( ) dif fers from the Sync channel only because it can non-deterministically lose data received from its source port. The SyncDrain ( ) has two source ends, and requires both ends to ha ve dataflow syn- chronously , or no dataflow is possible. The FIFO 1 channel ( ) has two possible states: empty or full. When empty , it can receiv e a data item from its source end, changing its state to full. When full, it can only send the data item receiv ed previously , changing its state back to empty . Finally , a replicator ( ) replicates data synchronously to all of its sink ends, while a merger ( ) copies data atomically from exactly one of its sink ends to its source end. Example 3 The connector on the right is an exclusive r outer b uilt by compos- ing two LossySync channels (b-e and d -g), one SyncDrain (c- f ), one Mer ger (h-i- f ), and thr ee Replicators (a-b-c-d , e- j -h and g-i-k). The constraints of these primitives can be combined to give the following two behavioural possi- bilities (plus the no-flow-everywher e possibility): • ends { a , b , c , d , e , f , h , j } synchr onise and a data item flows fr om a to j , • ends { a , b , c , d , f , g , i , k } synchr onise and a data item flows fr om a to k . a c b d f e g h i j k The merger makes a non-deterministic choice whenever both behaviours are possible. Data can nev er flo w from a to both j and k , as this is excluded by the beha vioural constraints of the Merger h - i - f . 3.1 Constraint automata W e briefly describe constraint automata [6]. Constraint automata use a finite set of port names N = { x 1 , . . . , x n } , where x i is the i -th port of a connector . When clear from the context, we write xyz instead of { x , y , z } to enhance readability . W e write b x i to represent the variable that holds the data value flowing through the port x i , and use b N to denote the set of data v ariables { b x 1 , . . . , b x n } , for each x i ∈ N . W e define D C X for each X ⊆ N to be a set of data constraints over the variables in b X , where the underlying data domain is a finite set D . Data constraints in D C N can be vie wed as a symbolic representation of sets of data-assignments, and are generated by the follo wing grammar: g :: = tt   b x = d   g 1 ∨ g 2   ¬ g where x ∈ N and d ∈ D . The other logical connectiv es can be encoded as usual. W e use the notation b a = b b as a shorthand for the constraint ( b a = d 1 ∧ b b = d 1 ) ∨ . . . ∨ ( b a = d n ∧ b b = d n ) , with D = { d 1 , . . . , d n } . Definition 5 (Constraint A utomaton [6]) A constraint automaton (over the finite data domain D ) is a tuple A = h Q , N , → , Q 0 i , wher e Q is a set of states, N is a finite set of port names, → is a subset of Q × 2 N × D C N × Q, called the transition r elation of A , and Q 0 ⊆ Q is the set of initial states. W e write q X | g − − → p instead of ( q , X , g , p ) ∈ → . For e very transition q X | g − − → p , we require that g , the guard, is a D C X -constraint. For e very state q ∈ Q , there is a transition q / 0 | tt − − → q . W e define CAS ⊆ 2 N × D C N to be the set of solutions for all possible labels of the transitions of constraint automata. That is, X | g ∈ CAS if X = { x 1 , . . . , x n } , g = V b x i = v i , where v i ∈ D , and there is a transition q X | g 0 − − → q 0 such that g satisfies g 0 . W e call each s ∈ CAS a constraint automaton step. Firing a transition q X | g − − → p is interpreted as having dataflo w at all the ports in X , while excluding flow at ports in N \ X , when the automaton is in the state q . The data flowing through the ports X must satisfy the constraint g , and the automaton ev olves to the state p . Figure 5 exemplifies the constraint automata for three Reo channels. W e do not define here the composition of constraint automata, but encode labels of constraint automata as labels of behavioural automata, whose composition has been defined in § 2.2. J. Proenc ¸ a, D. Clarke, E. de V ink & F . Arbab 73 q ab tt q a tt ab b a = b b empty full ( d ) a b a = d b b b = d Figure 5: From left to right, constraint automata for the SyncDrain, LossySync and FIFO 1 channels. q s 2 ( w ) s 1 ( v )   empty full ( v ) s 3 ( v ) s 4 ( v ) = q , empty q , full ( v ) s 2 ( w ) s 2 ( w ) s 1 ( v ) ⊗ s 3 ( v ) s 4 ( v ) s 2 ( w ) ⊗ s 4 ( v ) Figure 6: Composition of J A L K CA and J A F K CA , for any v , w ∈ D . 3.2 Constraint automata as beha vioural automata The CA model assumes a finite data domain D , and that data constraints such as tt , b a 6 = d , or b a = b b stand for simpler data constraints that use b a = d and the operators ∧ and ∨ . The encoding of the constraint automaton A = h Q , N , → CA , Q 0 i is the behavioural automaton J A K CA = h Q , L [ N ] , → BA , C i with L [ N ] , → BA , C , and the composition of labels defined as follo ws: • L = CAS , and α is defined as: α ( X | V n i = 1 b x i = d i ) = h N , X , / 0 , X , { x i 7→ d i } n i = 1 i . • W e hav e q X | g − − → BA q 0 for X | g ∈ L [ N ] if q X | g 0 − − → CA q 0 and g satisfies g 0 . • Let cas i = X i | g i be a solution for a label in a constraint automaton with ports N i , for i ∈ 1 .. 2. Then cas 1 ⊗ cas 2 =  ( X 1 ∪ X 2 ) | ( g 1 ∧ g 2 ) if X 1 ∩ N 2 = X 2 ∩ N 1 ∧ g 1  g 2 ⊥ otherwise where g 1  g 2 if for any port x ∈ X 1 ∩ X 2 and for any d ∈ D , x = d satisfies g 1 if f x = d satisfies g 2 . • C ( q ) = cp ( N ) for e very q ∈ Q . Recall that cp ( N ) = {  | α (  ) = h P , F , IP , OP , data i , P 0 ∩ F 6 = / 0 } . Example 4 Let A L = h Q L , N L , → 1 , Q 1 i and A F = h Q F , N F , → 2 , Q 2 i be the constraint automata of the LossySync and the FIFO 1 channels, depicted in F igure 5. The encoding of A L into behavioural automata is h Q L , L [ N L ] , → L , C L i , depicted in the left hand side of F igur e 6, wher e: Q L = { q } , N L = { a , b } , C L ( q ) = cp ( N L ) for q ∈ Q L , s 1 ( v ) = ab | ( b a = v ∧ b b = v ) , s 2 ( v ) = a | ( b a = v ) , and → L = {h q , s 1 ( v ) , q i | v ∈ D } ∪ {h q , s 2 ( v ) , q i | v ∈ D } . Similarly , the encoding of A F into behavioural automata is h Q F , L [ N F ] , → F , C F i , also depicted in F igur e 6, wher e: Q F = { empty } ∪ { full ( v ) | v ∈ D } , C F ( q ) = cp ( N F ) for q ∈ Q F , N F = { b , c } , s 3 ( v ) = b | ( b b = v ) , s 4 ( v ) = c | ( b c = v ) , and → F = {h empty , s 3 ( v ) , full ( v ) i | v ∈ D } ∪ {h full ( v ) , s 4 ( v ) , empty i | v ∈ D } . The composed automaton J A L K CA   J A F K CA is depicted in the right hand side of F igur e 6, wher e s 1 ( v ) ⊗ s 3 ( v ) = ab | ( b a = v ∧ b b = v ) and s 2 ( w ) ⊗ s 4 ( v ) = ac | ( b a = w ∧ b c = v ) . The composed automata presented in Example 4, which differs from the lossy-FIFO, is equi valent to the product of the two associated constraint automata [6], with respect to the atomic steps of the labels of the automata. W e expect this equiv alence to hold in general, but we do not gi ve a formal proof here. 74 Decoupled execution of synchronous coordination models 4 Encoding Linda Linda, introduced by Gelernter [15], is seen by many as the first coordination language. W e describe it using Linda-calculus [10], and sho w ho w it can be modelled using beha vioural automata. Linda is based on the generative communication paradigm, which describes ho w dif ferent processes in a distributed en vironment exchange data. In Linda, data objects are referred to as tuples , and multiple processes can communicate using a shar ed tuple-space , where they can write or read tuples. Communication between processes and the tuple-space is done by actions executed by processes ov er the tuple-space. In general, these actions can occur only atomically , that is, the shared tuple-space can accept and execute an action from only one of the processes at a time. There are four possible actions, out ( t ) , in ( s ) , rd ( s ) , and e val ( P ) . The actions out ( t ) and in ( s ) write and take v alues to and from the shared tuple-space, respecti vely . The action rd ( s ) is similar to in ( s ) , except that the tuple t is not remov ed from the tuple-space. Finally , eval ( P ) denotes the creation of a new process P that will run in parallel. W e do not address eval ( P ) here because it is regarded as a reconfiguration of the system. 4.1 Linda-Calculus W e use the Linda-Calculus model, described by Goubault [12], to give a formal description of Linda, studied also by Ciancarini et al. [10] and others. The Linda-Calculus abstracts away from the local behaviour of processes, and focuses on the communication primiti ves between a store and a set of pr o- cesses . Processes P are generated by the following grammar . P :: = Act . P   X   rec X . P   P 2 P   end (5) Ac t :: = out ( t )   in ( s )   rd ( s ) (6) W e denote the set of all Linda terms as Linda . The first case Act . P represents the e xecution of a Linda action. The productions X and rec X . P are used to model recursiv e processes, where X ranges over a set of variables, and P 2 P is used to model local non-deterministic choice. W e assume that processes do not hav e free variables, i.e., e very X is bound by a corresponding rec X . Finally end represents termination. W e model a Linda store as a multi-set of tuples from a global set T uple . Each tuple consists of a sequence of parameters, which can be either a data value v from a domain D (an actual parameter), or a v ariable X (a formal parameter). W e use the ⊕ operator to denote multi-set construction and multi-set union. For example, we write M = t ⊕ t = { | t , t | } and M ⊕ M = { | t , t , t , t | } , where t is a tuple and { | s , t | } denotes a multi-set with the elements s and t . A tuple-space term M is a multi-set of processes and tuples, generated by the grammar M :: = P | t | M ⊕ M . W e adopt the approach of Goubault and provide a set of inference rules that give the operational semantics of Linda-Calculus. A relation match ⊆ T uple × T uple represents the matching of two tuples. ( s , t ) ∈ match if t has only D v alues, and there is a substitution γ whose domain is the set of free v ariables of s , such that t = s [ γ ] . u [ γ ] denotes the tuple or process u after replacing its free v ari- ables according to γ . W e also write γ = P / x to denote the substitution of x by the process P , and say t γ -matches s when t matches s and t = s [ γ ] . Definition 6 (Semantics of Linda) The semantics of Linda is defined by the infer ence rules below . M ⊕ P [ rec X . P / X ] − → M ⊕ P 0 M ⊕ rec X . P − → M ⊕ P 0 (rec) M ⊕ P 2 P 0 − → M ⊕ P (left) M ⊕ P 2 P 0 − → M ⊕ P 0 (right) M ⊕ out ( t ) . P − → M ⊕ P ⊕ t (out) M ⊕ rd ( s ) . P ⊕ t − → M ⊕ P [ γ ] ⊕ t if t γ -matches s (rd) M ⊕ in ( s ) . P ⊕ t − → M ⊕ P [ γ ] if t γ -matches s (in) M ⊕ end − → M (end) J. Proenc ¸ a, D. Clarke, E. de V ink & F . Arbab 75 Example 5 The following sequence of transitions illustrates the sending of data between two pr ocesses. The labels on the arr ows contain the names of the rules applied in eac h transition of Linda-Calculus. W e use the notation P ( x ) as syntactic sugar to denote a pr ocess P wher e the variable x occurs fr eely . rd ( 42 , x ) . P ( x ) ⊕ out ( 42 , 43 ) . end ⊕ in ( 42 , x ) . P 0 ( x ) ( out ) − − → rd ( 42 , x ) . P ( x ) ⊕ end ⊕ in ( 42 , x ) . P 0 ( x ) ⊕ h 42 , 43 i ( end ) − − − → rd ( 42 , x ) . P ( x ) ⊕ in ( 42 , x ) . P 0 ( x ) ⊕ h 42 , 43 i ( rd ) − − → P ( 43 ) ⊕ in ( 42 , x ) . P 0 ( x ) ⊕ h 42 , 43 i ( in ) − − → P ( 43 ) ⊕ P 0 ( 43 ) 4.2 Linda-calculus as beha vioural automata W e define an encoding function J · K Linda : Linda → BA , from Linda tuple-space terms to behavioural automata. Furthermore, we define the composition of atomic steps that preserve this semantics. W e encode each Linda process P as a behavioural automaton, and we create a special beha vioural automaton that describes the multi-set of av ailable tuples. Let Act = { a | a ∈ Act } and τ Act = { τ a | a ∈ Act } . A port a is regarded as a dual port of a , and flo w of data on a port τ a represents the flow on the ports a and a simultaneously . The intuition is that the encoding of processes yields behavioural automata whose ports are actions in Act ; the encoding of tuples yield beha vioural automata whose ports are dual actions in Act ; and the composition forces actions and dual actions to synchronise, i.e., to occur simultaneously . W e define the global set of ports to be P = Act ∪ Act ∪ τ Act , and define a = a . Let M = P 1 ⊕ · · · ⊕ P n ⊕ T be a tuple-space term. In turn, let T = t 1 ⊕ · · · ⊕ t m and m ≥ 0. W e define the encoding of M into a beha vioural automaton as follows. J M K Linda = J P 1 K Linda   · · ·   J P n K Linda   J T K Linda Hence, encoding M boils down to encoding Linda processes P i and the Linda tuple-space T into dif ferent behavioural automaton. In both encodings of components and Linda tuple-spaces we define labels L as ports, that is, L = P = Act ∪ Act ∪ τ Act , and its encoding as atomic steps by the function α defined belo w . α ( a ) =  h P , { a , τ act } , / 0 , / 0 , / 0 i if a ∈ Act ∪ Act , { act } = { a , a } ∩ Act h P , { a } , / 0 , / 0 , / 0 i if a ∈ τ Act The composition of two labels a 1 , a 2 ∈ L is defined as follo ws. a 1 ⊗ a 2 =  τ act if a 1 / ∈ τ Act ∧ a 2 / ∈ τ Act ∧ a 1 = a 2 ⊥ otherwise, where { act } = { a 1 , a 2 } ∩ Act . The tuple-space is used to enforce ev ery action a performed by a process to synchronise with the corresponding action a in the tuple-space encoded as a behavioural automaton. The definition of ⊗ replaces every pair of ports with dataflo w a and a by a new port with dataflow in τ act . W e encode a Linda process P as J P K Linda = h Q P , L , → P , C i , with components as defined belo w . • The set of states Q P is gi ven by Q P = reac h ( P ) , where r each ( out ( t ) . P ) = { out ( t ) . P } ∪ r each ( P ) r each ( rd ( s ) . P ) = { rd ( t ) . P } ∪ ( S { r each ( P [ γ ]) | s γ -matches t } ) r each ( in ( s ) . P ) = { in ( t ) . P } ∪ ( S { r each ( P [ γ ]) | s γ -matches t } ) r each ( P 2 P 0 ) = { P 2 P 0 } ∪ r each ( P ) ∪ r each ( P 0 ) r each ( end ) = { end } 76 Decoupled execution of synchronous coordination models • The transition relation → P is gi ven by the follo wing conditions. out ( t ) . P 0 out ( t ) − − − → P 0 if t ∈ T uple P 1 2 P 2 s − − → P 0 1 if P 1 s − → P 0 1 rd ( s ) . P 0 rd ( t ) − − → P 0 [ γ ] if s γ -matches t P 1 2 P 2 s − − → P 0 2 if P 2 s − → P 0 2 in ( s ) . P 0 in ( t ) − − → P 0 [ γ ] if s γ -matches t • C ( q ) = Act ∪ Act for every state q . W e now encode a Linda tuple-space T as J T K Linda = h Q T , L , → T , C i with components as defined belo w . • Q T = 2 M ( T uple ) , where M ( X ) is a multi-set o ver the set X . • The transition relation → T is gi ven by the follo wing conditions: M out ( t ) − − − → M ⊕ t if t ∈ T uple , t ⊕ M rd ( s ) − − − → t ⊕ M if s matches t , and t ⊕ M in ( s ) − − → M if s matches t . • C ( q ) = Act ∪ Act for every state q , as in the encoding of Linda processes. Note that the input and output ports of the atomic steps obtained with α , introduced in § 2.1, are always the empty set, that is, the data value flowing through the ports is not relev ant, since the name of the port uniquely identifies the data. Alternativ e approaches to implement the encoding into behavioural automata that use the data v alues are also possible, but less transparent. Example 6 Recall the example pr esented in the end of § 4.1 of a sequence of tr ansitions of a tuple-space term in Linda-Calculus. W e pr esent below a simplified version of this e xample. rd ( 42 , x ) . P ( x ) ⊕ out ( 42 , 43 ) . P 0 ( out ) − − → rd ( 42 , x ) . P ( x ) ⊕ P 0 ⊕ h 42 , 43 i ( rd ) − − → P ( 43 ) ⊕ P 0 ⊕ h 42 , 43 i The corr esponding transitions in the encoded behavioural automaton ar e pr esented below . J rd ( 42 , x ) . P ( x ) K Linda   J out ( 42 , 43 ) . P 0 K Linda   J / 0 K Linda τ out ( 42 , 43 ) − − − − − → J rd ( 42 , x ) . P ( x ) K Linda   J P 0 K   J h 42 , 43 i K τ rd ( 42 , 43 ) − − − − → J P ( 43 ) K Linda   J P 0 K   J h 42 , 43 i K Observe that we assume an initial empty tuple-space, which is encoded as J / 0 K Linda . A more careful analysis shows a one-to-one correspondence between the traces of the Linda-calculus term and the traces of the behavioural automaton, which we do not elaborate in this paper . 5 Exploiting concurr ency predicates W e introduced a unified model for synchronous coordination that explicitly mentions concurrency pred- icates, which indicate which actions require synchronisation. W e now exploit more complex definitions of concurrent predicates for Reo and Linda than in our previous examples, and briefly describe a practical application of behavioural automata in a distrib uted framework. J. Proenc ¸ a, D. Clarke, E. de V ink & F . Arbab 77 5.1 Complex concurrency pr edicates In our examples concurrency predicates of Reo hold when some shared ports from a composed automaton hav e dataflo w (Equation (1)), and concurrency predicates of Linda allo w only a special set of actions τ Act to run concurrently . W e now present other concurrency predicates that capture notions such as context dependency and priority . Reo Other semantic models for Reo , such as connector colouring [11] and Reo automata [8], capture the notion of conte xt dependency , a feature missing in constraint automata. By modelling context depen- dency we av oid the undesired behaviour of the composed connector in Figure 6 where data is lost when the FIFO 1 buf fer is empty , represented by the label s 2 ( w ) . T o av oid data from being lost, we replace the LossySync channel by a context dependent LossySync channel, which is built based on the LossySync channel by replacing the label s 2 ( w ) by a label s b 2 ( w ) . This new label has the same atomic step, i.e., α ( s 2 ( w )) = α ( s b 2 ( w )) , but can be e xecuted in parallel only if its neighbours require the port b to have no dataflow . This condition is enforced by adapting the definition of concurrency predicates to check wether a gi ven set of ports Y requires synchronisation. cp ctx ( P 0 , Y ) =  s X | s X ∈ cp ( P 0 ) ∨ X ∩ Y 6 = / 0  (7) In our example, we a void the losing of data by defining C ( q ) = cp ctx ( ab , / 0 ) , C ( empty ) = cp ctx ( bc , b ) , and C ( full ( v )) = cp ctx ( ab , c ) . The label s b 2 ( w ) is in C ( empty ) but not in C ( full ) , i.e., s b 2 ( w ) can be performed independently of the FIFO 1 channel only when the FIFO 1 is full. Other important details, such as the composition of labels of the form s X , are not presented in this paper . A more precise and complete formulation can be found in Proenc ¸ a’ s Ph.D. thesis (Sections 3.6.2 and 4.4.2 of [18]). Linda Consider no w that Linda processes have a total order  , representing a ranking among processes. When two processes can interact simultaneously with the shared tuple-space, only the higher rank should be chosen. W e present only a sketch of this approach due to space limitation. W e start by tagging labels  of the Linda beha vioural automata with the process that executes it. For example, a label  of an automaton of a process p is renamed to  p . Labels of the shared tuple- space are not changed. The composition of labels must be such that  p ⊗  = τ p  . It is then enough to change the concurrency predicates of the automata of each process p in state q to C ( q ) = Act ∪ Act ∪  τ x  | τ  ∈ τ Act ∧ x  p ∧ q 6 = end  and leave the concurrenc y predicate of the automaton of the shared tuple-space unchanged. Hence, a transition cannot be performed in parallel if it is in Act or Act , or if it is a τ action from a process with lower priority and the current process is not yet stopped. 5.2 Increased scalability via decoupled execution W e use the behavioural automata model in a distributed frame work, Dreams , where se veral independent threads run concurrently [18]. Each thread has its o wn behavioural automaton, and communicates only with those threads whose behavioural automata share ports with its o wn automata. The details re garding this tool are out of the scope this paper , but we explain ho w it benefits from using beha vioural automata. The diagram in Figure 7 depicts the configuration of a system in Dreams , where each cloud represents an independent thread of execution, and edges represent communication links between threads whose automata share ports. The direction of each edge only illustrates the e xpected direction of dataflow . For ef ficiency reasons, and to allow a lightweight reconfiguration, Dreams does not create the complete behavioural automaton of a connector . Instead, it collects only the behaviour of the current round. 78 Decoupled execution of synchronous coordination models connector 1 connector 2 LF A C r eader a’ b a c Figure 7: Configuration of a system in Dreams . Kno wing that only the labels of the automata relev ant for the current round are composed, and as- suming that the locality property introduced in Definition 4 holds, we can perform local steps that, as the name suggests, in volv e only a subpart of the system. Recall the example of the lossy alternator , presented in § 2.3. The diagram in Figure 7 uses the same example, in a context where two arbitrary lar ge connectors connector 1 and connector 2 are attached to the source of the lossy alternator , and a r eader component is attached to the sink of the lossy alternator . Consider that the r eader can alw ays recei ve any data v alue, that is, its beha vioural automaton has a single state, and a transition labelled by r ( v ) for e very data v alue v , such that α ( r ( v )) = h c , c , c , / 0 , { c 7→ v }i . Observe that we do not use explicitly the composed connector LF   AC , but LF and AC as inde- pendent entities instead, since the Dreams framew ork can postpone the composition of their labels to runtime. Consider that the A C automaton is in state q 1 ( v ) , hence it can perform a step s 2 ( v ) , writing a v alue v to the port c . In this example AC is connected via the ports a , b , and c . The label s 2 ( v ) does not hav e dataflow on a nor on b , and the reader can perform a label r ( v ) because s 2 ( v ) ⊗ r ( v ) 6 = ⊥ . Using the concurrenc y predicate in Equation (1), we conclude that s 2 ( v ) ⊗ r ( v ) is in the concurrenc y predicates of LF and connector 2 . Furthermore, from the locality property we conclude that all other connectors not attached to AC also allow s 2 ( v ) ⊗ r ( v ) to be e xecuted concurrently . Hence, Dreams can chose to perform this step by analysing only the behaviour of A C and r eader , depicted by a gre y box. The instantiations of Linda and Reo yield a similar result. The shared tuple-space can communicate with a single process at a time, without synchronising with every other process. Reo can, for example, send data from a full FIFO 1 independently of the behaviour of the connector attached to its sink port. The benchmarks performed for the Dreams framew ork [18] show optimistic results regarding the use of local steps in synchronous coordination. 6 Conclusion W e introduce beha vioural automata to model coordination systems. The three main concepts that under- lie behavioural automata are atomicity , composability , and dataflow . W e allo w a sequence of actions that cannot be interleav ed with interfering instructions (atomicity), we construct more complex systems out of building blocks that can be analysed independently (composability), and we represent the data values that are exchanged between components (dataflo w). Behavioural automata unify existing dataflo w-oriented models with synchronous constructs by lea v- ing open the definitions of composition of labels and of concurrency predicates. The focus of behavioural automata is on concurrent systems, and on av oiding synchronisation of actions whenev er it is unneces- sary . By capturing a multitude of coordination models, we allo w any of these models to be included in implementations based on behavioural automata, such as the Dreams frame work. As future work, we expect to formally show the correctness of the encodings of Reo and Linda. W e J. Proenc ¸ a, D. Clarke, E. de V ink & F . Arbab 79 would also like to discover which properties can be shown for behavioural automata that are directly reflected on encoded models. A more practical track of our work in volv es the dev elopment of tools. Further de velopment of Dreams to make it ready for use by a broader community is in our agenda. Refer ences [1] Farhad Arbab (2004): Reo: a channel-based coor dination model for component composition. Mathematical Structures in Computer Science 14(3), pp. 329–366, doi:10.1017/S0960129504004153. [2] Farhad Arbab (2005): Abstract Behavior T ypes: a foundation model for components and their composition . Science of Computer Programming 55, pp. 3–52, doi:10.1016/j.scico.2004.05.010. [3] Farhad Arbab (2006): Composition of Interacting Computations , chapter 12, pp. 277–321. Springer-V erlag New Y ork, Inc., Secaucus, NJ, USA, doi:10.1007/3-540-34874-3 12. [4] Farhad Arbab, Roberto Bruni, Da ve Clark e, Ivan Lanese & Ugo Montanari (2009): T iles for Reo . In: Recent T rends in Algebraic Development T echniques , LNCS 5486, Springer , pp. 37–55, doi:10.1007/978-3-642- 03429-9 4. [5] Farhad Arbab, Christian K oehler , Ziyan Maraikar, Y oung-Joo Moon & Jos ´ e Proenc ¸ a (2008): Modeling, testing and executing Reo connector s with the Eclipse Coor dination Tools . In: Proceedings of F A CS , SCP . [6] Christel Baier , Marjan Sirjani, Farhad Arbab & Jan J. M. M. Rutten (2006): Modeling component connectors in Reo by constraint automata . Science of Computer Programming 61(2), pp. 75–113, doi:10.1016/j.scico.2005.10.008. [7] G ´ erard Berry (2000): The foundations of Ester el . In Gordon D. Plotkin, Colin Stirling & Mads T ofte, editors: Proof, Language, and Interaction , The MIT Press, pp. 425–454. [8] Marcello M. Bonsangue, Dav e Clarke & Ale xandra Silva (2009): Automata for Conte xt-Dependent Connec- tors . In: COORDINA TION , LNCS 5521, Springer , pp. 184–203. [9] D. M. Chapiro (1984): Globally-Asynchr onous Locally-Synchr onous Systems . Ph.D. thesis, Standford Uni- versity . [10] P . Ciancarini, K.K. Jensen & D. Y ankelevich (1995): On the Operational Semantics of a Coordination Lan- guage . In: Object-Based Models and Languages for Concurrent Systems , LNCS 924, pp. 77–106. [11] Dav e Clarke, Da vid Costa & Farhad Arbab (2007): Connector colouring I: Synchr onisation and context dependency . Science of Computer Programming 66(3), pp. 205–225, doi:10.1016/j.scico.2007.01.009. [12] R ´ egis Cridlig & Eric Goubault (1993): Semantics and Analysis of Linda-Based Languages . In Patrick Cousot, Moreno Falaschi, Gilberto Fil ´ e & Antoine Rauzy , editors: WSA , LNCS 724, Springer , pp. 72–86. [13] Frederic Doucet, Massimiliano Menarini, Ingolf H. Kr ¨ uger , Rajesh K. Gupta & Jean-Pierre T alpin (2006): A V erification Appr oach for GALS Inte gration of Synchr onous Components . ENTCS 146(2), pp. 105–131. [14] Fabio Gadducci & Ugo Montanari (2000): The tile model , pp. 133–166. MIT Press, Cambridge, MA, USA. [15] David Gelernter (1985): Generative communication in Linda . ACM Transactions on Programming Lan- guages and Systems 7(1), pp. 80–112, doi:10.1145/2363.2433. [16] Christian Krause (2011): Reconfigurable component connectors . Ph.D. thesis, Leiden Univ ersity . [17] Robin Milner (1983): Calculi for Synchr ony and Asynchr ony . Theor . Comput. Sci. 25, pp. 267–310, doi:10.1016/0304-3975(83)90114-7. [18] Jos ´ e Proenc ¸ a (2011): Synchr onous Coor dination of Distrib uted Components . Ph.D. thesis, Leiden Univ ersity .