Springer - Concurrency Theory Episode 6 pdf

186 6 Beyond pbLOTOS B 1 [>B 2 which states that behaviour B 2 can disable behaviour B 1 . We call B 1 the normal behaviour and B 2 the exception behaviour.Atanypointduringthe evolution of B 1 , the first action of B 2 can be performed, causing B 1 to be stopped and B 1 [>B 2 to behave as B 2 . In fact, even before B 1 has performed an action, B 2 can disable it. Once B 1 has successfully terminated, it can no longer be disabled. For example, consider the following behaviours. (i) x ; y ; exit [>w; z ; stop (ii) P [>w; z ; stop where, P := x ; y ; P (iii) x ; y ; stop [>w; z ; stop (iv) x ; y ; exit [>i; z ; stop (v) ( x ; y ; exit [>w; z ; stop ) >> v ; stop Behaviour trees for these expressions are depicted in Figure 6.1. The following point s can be made on each example behaviour. (i) The exception behaviour, w ; z ; stop,isofferedasanalternativetoper- forming any action in the normal behaviour. Thus, at any point, the nor- mal behaviour can be disabled, that is, until a successful termination action is performed. (ii) Because the normal behaviour has an infinite character, there is no suc- cessful termination to disable the exception behaviour. (ii) This behaviour cannot successfully terminate, thus, the exception be- haviour cannot be disabled and must happen after the normal behaviour has completed. (iv) An asymmet ric nondeterministic choice is generated between performing the normal behaviour observably or internally evolving to the exception behaviour. (v) This behaviour illustrates the interplay of disabling and successful termi- nation. Specifically, successful termination of the normal behaviour en- ables the new behaviour v ; stop. The disable operator is not a standard process calculus operator (although, its origins date back to [96]); rather it is targeted at the specific application domain of LOTOS: description of communication protocols. In this context, it is used to express the disrupting effect of error and exception behaviour, e.g. a connection being unexpectedly disconnected. We have not included disabling in pbLOTOS because it has some unpleasant semantic consequences. For ex- ample, disabling cannot be expressed easily using the bundle event structure true concurrency semantics that were considered in Chapter 4. Three simple operational semantics rules can be given for the behaviour of the disabling operator. 6.1 Basic LOTOS 187 (ii) (i) δ δ (iii) i i (iv) i z (v) x w z y w z z w w z x w z y z z w w x w z y z z y x z z w z w w y x v i Fig. 6.1. Disabling Examples 188 6 Beyond pbLOTOS (DIS.i) : B 1 a −→ B  1 B 1 [>B 2 a −→ B  1 [>B 2 (a = δ) (DIS.ii) : B 1 δ −→ B  1 B 1 [>B 2 δ −→ B  1 (DIS.iii) : B 2 a −→ B  2 B 1 [>B 2 a −→ B  2 (a ∈ Act ∪{i, δ}) Thus, rule (DIS.i) ensures that any nonterminating action that B 1 can per- form, can be performed by B 1 [>B 2 and the capacity to disable remains. Rule (DIS.ii) states that a successful termination on the part of B 1 , will success- fully terminate the disabling. Finally, rule (DIS.iii) indicates how a transition of B 2 can disable the evolution of B 1 . 6.1.2 Generalised Choice Generalised choice has the form, choice ge 1 , ,ge n [] B where ge i is a gate expression of the form: xin[x 1 , ,x m ] which states that the variable x ranges over the set [x 1 , ,x m ]; i.e. can be instantiated with any of the actions x 1 , ,x m . Generalised choice allows us to express behaviour such as choice x in [v, z,w],yin[u, w][]B  which is equivalent to the following B  [v/x,u/y][]B  [z/x, u/y][]B  [w/x, u/y][] B  [v/x,w/y][]B  [z/x, w/y][]B  [w/x, w/y] So, the choice of a series of instances of B  is generated, where each instance reflects a particular instantiation of x and y. As suggested by this example, generalised choice enables us to express a large class of behaviours significantly more succinctly than they would be expressed with basic (binary) choice. In addition, we can express infinite choices using generalised choice (such behaviour cannot be expressed using basic choice). This particularly becomes clear when we discuss the integration of data with generalised choice in the next section. However, a specific case of infinite choice is given by the following behaviour, choice x in Act [] B where B usually refers to x 6.1 Basic LOTOS 189 which defines an infinite choice of behaviour B instantiated with actions from the (infinite) set of all possible LOTOS actions. A simple operational semantics rule can be given for the behaviour of generalised choice. B[x i /x] a −→ B  choice x in [x 1 , ,x n ][]B a −→ B  (1 ≤ i ≤ n) This rule assumes just a single action binder, xin[x 1 , ,x n ], however, it can easily be generalised to multiple action binders. 6.1.3 Generalised Parallelism Generalised parallelism has the form, par ge 1 , ,ge n |[x 1 , ,x m ]| B For example, the behaviour: par x in [v,z, w],yin[u, w] |[w]| B  is equivalent to: B  [v/x,u/y] |[w]| B  [z/x, u/y] |[w]| B  [w/x, u/y] |[w]| B  [v/x,w/y] |[w]| B  [z/x, w/y] |[w]| B  [w/x, w/y] It should be noted that the parallel composition operator, |[w]| above, cannot be affected by the instantiation of action names. This construct plays a similar role to generalised choice, but in the context of parallel behaviour. Rather than giving inference rules specific to this operator, as we did for generalised choice, we simply provide a mapping from generalised parallelism to a sequence of normal binary parallel compositions. This is possible because the number of parallel threads that can be generated with this operator is always finite (in contrast, generalised choice can yield infinite choices). par x in [y 1 , ,y n ] |[x 1 , ,x m ]| B  B[y 1 /x] |[x 1 , ,x m ]| |[x 1 , ,x m ]| B[y n /x] Again our rule is specific to a single action binder, but it could also easily be generalised to multiple action binders. Another reason why this mapping is well-formed is because in pbLOTOS, parallel composition is associative when synchronisation sets are repeated. That is, an expression of the form, B 1 |[x 1 , ,x m ]| |[x 1 , ,x m ]| B n defines a unique behaviour, because any bracketing that decomposes the expression into a sequence of binary compo- sitions would be equivalent up to strong bisimulation. 190 6 Beyond pbLOTOS 6.1.4 Verbose Specification Syntax The top-level syntax for a bLOTOS specification has the following form, specification I [x 1 , ,x n ]:F behaviour endspec where I is an identifier that names the specification, x 1 , ,x n are the ob- servableactionsoftheentirespecificationandF denotes the functionality of the specification. These extensions to the top-level specification syntax of pbLOTOS are largely syntactic sugar. The body of the specification appears between the keywords behaviour and endspec. This behaviour will have the form: B where D 1 D n where B is an arbitrary behaviour and D i is a process definition. Although the list of declarations could be empty. The functionality parameter, F, states that the specification either has the functionality exit or noexit. A specification that can successfully terminate has the functionality exit, whereas a specification that is unable to successfully terminate has the functionality noexit. Rules for determining the functionality of specifications are given in [24]. 6.1.5 Verbose Process Syntax In a similar way, a verbose process syntax is used in bLOTOS, process P [x 1 , ,x n ]:F := endproc where P is the process identifier; x 1 , ,x n are the observable actions of the process; F denotes the functionality of the process; i.e. exit or noexit in the same way as for complete specifications; and the body of the process is between thesymbol:=andendproc. This behaviour will typically have the form: 6.1 Basic LOTOS 191 B where D 1 D n where B is an arbitrary behaviour and D i is a process definition. In fact, the similarity between the syntax of process definitions and the top-level structure of specifications is not surprising, because a specification, as a whole, can be seen to be a process. A specification is a special kind of process, but only by virtue of its name. 6.1.6 Syntax of bLOTOS This section brings together the constructs that we have introduced to give an abstract syntax for bLOTOS. The syntax defines an arbitrary specification S ∈ bLOTOS as follows. S ::= specification I [x × ]:F behaviour U endspec U ::= B | B where D + D ::= process P [x × ]:F := Uendproc B ::= stop | exit | a ; B | B 1 [] B 2 | B 1 |[x × ]| B 2 | B 1 >> B 2 | B 1 [>B 2 | choice ge + [] B | par ge + |[x × ]| B | hide x + in B | B[(x/y) + ] | P [x × ] F ::= exit | noexit ge ::= yin[x + ] where • We have used BNF notation in which X + denotes a finite number, bigger than zero, of repetitions of X and Y × denotes a finite number, including zero, of repetitions of Y , which are separated by commas, if there is more than one; • S is the domain of specifications, U is the domain of top-level behaviours, D is the domain of definitions, B is the domain of behaviour expressions, F is the domain of functionality parameters and ge are action binders; • The domain D has changed from pbLOTOS; here we are using it to range over single definitions; and • a ∈ Act ∪{i}, x, y ∈ Act, I,P ∈PIdent. 1 1 Note, we do not distinguish the domain of specification names from that of process names. 192 6 Beyond pbLOTOS 6.2 Full LOTOS As indicated earlier, full LOTOS integrates the constructs introduced above with a data typing notation, ACT-ONE. A complete presentation of this no- tation is inappropriate for a number of reasons. • Our main interest in this book is the behavioural part of LOTOS. • The ACT-ONE data language has proved a troublesome part of full LO- TOS. There are a number of reasons for this, which we do not have room to consider here; see, for example, [150] for a discussion of this issue. How- ever, a central issue is that ACT-ONE is not in practice easy to use. In particular, even trivial specifications, such as that of the natural numbers, prove complex to express in ACT-ONE. • LOTOS restandardisation has designed a new data language to replace ACT-ONE; see Section 6.4. Thus, in the LOTOS context, ACT-ONE is largely obsolete. However, we now give a flavour of the interface between data and behaviour provided by full LOTOS. In order to do this, we assume a basic set of data types that are not tied to any particular data language; i.e. natural numbers, Booleans and enumerated types. We show how these can be interfaced with LOTOS. So, we assume the following primitive set of data domains. • Asetnat of natural numbers, with 0, 1, 2, 3, ∈ nat and operations + and relations =,>,<, etc. defined on nat; we also have an operator comp, which takes the complement of 0 and 1; i.e. comp(0) = 1 and comp(1) = 0; • Asetint of integers, with ,−3, −2, −1, 0, 1, 2, 3, ∈ int and operations +, − and relations =,>,<, etc. defined on int; • Asetbool of Booleans, with two elements, true and false, and operations not, and, or etc. defined on bool;and • Four enumerated types that are used in the Dining Philosophers example: name ::= Aristotle | Buddha | Confucius | Descartes side ::= left | right action ::= eat | think chopstick ::= stick1 | stick2 | stick3 | stick4 These are presented in a standard way using BNF. These definitions state that the type name can have four constant values, Aristotle, Buddha, Confucius and Descartes, and similarly for side, action and chopstick. As was the case with bLOTOS, for each of the new constructs we introduce, we provide operational semantics rules to illustrate how these constructs are interpreted in a labelled transition systems semantics. However, as stated earlier, these semantics are presented as a taster, rather than as an exhaustive semantic definition. We present the fLOTOS extensions to bLOTOS construct by construct. 6.2 Full LOTOS 193 6.2.1 Guarded Choice Conditional selection based on the value of variables can be defined. There are three basic ways to define data conditionals in fLOTOS: guarded commands, selection predicates and generalised choice. We consider the first of these here. The other two are considered when we have described value passing actions. Guarded choice is derived from Dijkstra’s guarded commands notation; it has the following general form, [be] −>B [] [be  ] −>B  where be and be  are Boolean expressions. The meaning of this construct is: if the guard be holds, behave as B, otherwise, if the guard be  holds, behave as B  . Notice that if the guards overlap, nondeterminism can be created. In fact, any arbitrary piece of behaviour can be prefixed with a guard. Thus, the choice here is not even required and the basic syntactic enhancement that arises with guards is the capacity to “prefix” any arbitrary behaviour with aguard.Thus, [be] −>B Semantically, this construct is interpreted via the following inference rule, B a −→ B  beval(be) ([be] −>B) a −→ B  where a ∈ Act ∪{i, δ} 2 and beval evaluates the Boolean expression be in the obvious way. Notice that the LOTOS semantics ensure that be only contains ground terms. Thus, beval does not require a state or environment in order to evaluate a Boolean expression. 6.2.2 Specification Notation The top-level syntax for an fLOTOS specification has the following form, specification I [x 1 , ,x n ](n 1 : T 1 , ,n m : T m ): F TD behaviour B where TD D × endspec 2 Although, with fLOTOS actions are more complex, because they carry data attributes. This is an issue we elaborate on shortly. 194 6 Beyond pbLOTOS where TD is a list of type definitions and D + is a list of process definitions. The TDs in the above specification indicate places where ACT-ONE definitions can legally be placed in LOTOS specifications. The type definitions that follow the specification header would be global, over the entire specification, whereas the type definitions following the where keyword only range over the list of process definitions. In addition, the list (n 1 : T 1 , ,n m : T m ) parameterises the specification on a group of data variables with associated types, which can be instantiated on execution of the specification. So, these are data values that are input to the specification. 6.2.3 Process Definition and Invocation The fLOTOS syntax for process definition is: process P [x 1 , ,x n ](n 1 : T 1 , ,n m : T m ):F := B where TD D × endproc Thus, process definition takes a very similar form to the top-level specification syntax. In particular, processes are parameterised on certain variables and local data type and process definitions can be included following the keyword where; although, these are all optional. This parameterisation means that process invocation takes on a somewhat more complicated form than it did for pbLOTOS and bLOTOS. Given the above process definition, process invocation takes the following general form, P [y 1 , ,y n ](E 1 , ,E m ) where E i is a value expression of type T i . The effect of this invocation is to textually substitute the expressions E i in place into the process body for their corresponding formal parameter; i.e. n i . This class of parameter passing is similar to call by name as used in standard programming languages. 6.2.4 Value Passing Actions In fLOTOS, actions can exchange data. As a reflection of this, we distinguish between gates and actions and we assume variables g, g  ,g  ,g 1 ,g 2 , ranging over the set Gate. Actions now have the general form: gd 1 d n 6.2 Full LOTOS 195 i.e. action instances comprise a gate and a list of value and variable decla- rations,denotedd i (these are sometimes called experiment offers and what we call value and variable declarations are called value experiments and vari- able experiments). For example, in the communication protocol example, we might want to specify that, when a send is performed, a natural number is passed with the send. This number could, for example, be used to associate a sequence number with messages. The following are typical data valued action instances occuring in this setting, send!5 ,send!(10 + 2) ,send!n, send!(10 + n) ,send?m : nat In these action instances, send isthegatenameand!5, !(10+2), !n, !(10+n) and ?m : nat are data passing declarations. In particular, !5, !(10+2), !n and !(10+n) are value declarations, whereas ?m : nat is a variable declaration. The effect of a value declaration is to pass a data value (here a natural number). So, the effect of send!20 is to offer an interaction at the gate named send and associate the value 20 with that interaction, whereas send!n offers interaction on the same gate, but, this time, the value of the variable n is associated with the interaction. In contrast, the effect of a variable declaration is to offer a variable to which a binding can be made. So, the effect of send?m : nat is to offer an interaction at the gate named send and associate a binding to variable m with that interaction. In effect, the declaration ?m : nat states that m can take any value from the natural numbers. Notice that one implication of value passing is that specifications will now typically have an infinite set of possible actions. Thus, the set L can now be infinite. For example, for the behaviour, P := send? m : nat ; stop L = { send 0,send 1,send 2, },wheresend v denotes interaction at gate send with an associated data value v. In fact, this style of action denotation plays a central role in the fLOTOS semantics. Specifically, labels in transition systems will now have the form, g v 1 v 2 v n where the v i s are data values. Thus, effectively, data is “flattened out” when the semantics are applied. For example, the transition system arising from process P above is shown in Figure 6.2. One beneficial consequence of this flattening of data is that the standard development relations introduced in Part II can be applied in this context, subject to the problems that may arise with infinite branching. 3 Effectively, these relations just treat the complex flattened labels that arise from fLOTOS in the same way as the pure action names that arise from pbLOTOS. Thus, 3 Of course, we are here talking from a theoretical perspective, because it is clear that such infinite branching is a major difficulty for the development of verification tools for data passing calculi. [...]... LOTOS are feasible, e.g axiomatisation [28] Such investigations will be harder with E-LOTOS In fact, in some respects, E-LOTOS is running against the tide of concurrency theory research, which has been moving in the direction of pared down tractable notations; i.e that are amenable to formal verification In contrast, E-LOTOS adds functionality at the expense of ease of verification and tractability This... generalised choice, choice n : T [] a!n ; B is equivalent to the action prefix a?n : T ; B As an example of the relationship between ! and ?, we could re-express the fragment of receiver behaviour highlighted at the end of the previous Section (6. 2 .6) as follows 204 6 Beyond pbLOTOS choice n : nat [] ( [n = m] −> receive!n ; put ; sendAck!n ; Receiver[put, receive, sendAck](comp(m)) [] [n = m ∧ n ≤ 1] −> receive!n... the use of disabling in the fragment highlighted at the end of the previous section (6. 2 .6) , allows the exception behaviour to be initiated at any point during the execution of the normal behaviour In conclusion then, generalised choice can either be parameterised on sets of actions (see Section 6. 1.2) or data types 6. 2.8 Parameterised Enabling Sequential composition, also called enabling, B1 >> B2... follows, (∗ ∗) 6 Again, we do not distinguish the domain of specification names from that of process names 6. 3 Examples 207 6. 3 Examples As an illustration of fLOTOS, we present complete specifications of the two running examples that we have been using: the communication protocol and the Dining Philosophers.7 Together, these specifications illustrate the major features of fLOTOS 6. 3.1 Communication... protocol (at the receiver end) Finally, the CADP specification also includes the possibility that the mediums can 210 6 Beyond pbLOTOS 6. 3.2 Dining Philosophers Assuming the definition of the constant data types, name, side, action and chopstick, introduced at the beginning of Section 6. 2, the top-level behaviour of the Dining Philosophers can be specified as follows specification philo [pick, put] : noexit...1 96 6 Beyond pbLOTOS send_0 send_1 Fig 6. 2 Flattening of Data reassuringly, all theory developed in the pbLOTOS setting is still applicable in the fLOTOS setting In our general form of action, the di s can have one of the following forms, !E... parallel and, thus, resolve the choice As an illustration of this form of value synchronisation, Figure 6. 3 depicts the choice of possible immediate evolutions of a typical behaviour of this form g?m:nat;B |[g]| g?n:nat;B’ g_0 g_1 B[0/m] |[g]| B’[0/n] B[1/m] |[g]| B’[1/n] Fig 6. 3 Value Generation Example 6. 2.4.2 Value Passing and Internal Behaviour Hidden behaviour is also affected by value passing Firstly,... Section 6. 2.4.1, the behaviour of the receiver could be specified as follows process Receiver [put, receive, sendAck](m : nat) : noexit := hide timeout in ( timeout; sendAck!comp(m); Receiver[put, receive, sendAck](m) [] receive?n : nat; ( [m = n] −> put; sendAck!n; Receiver[put, receive, sendAck](comp(m)) [] [m = n] −> sendAck!n; Receiver[put, receive, sendAck](m) ) ) endproc 6. 3 Examples 209 The top-level... hide g in ( B |[g]| B’[5/n] ) (i) (ii) hide g in ( g?m:nat;B |[g]| g?n:nat;B’ ) i i hide g in ( B[0/m] |[g]| B’[0/n] ) (iii) hide g in ( B[1/m] |[g]| B’[1/n] ) Fig 6. 4 Value Generation Examples and Internal Behaviour 200 6 Beyond pbLOTOS 6. 2.4.3 Illustration of Value Passing Examples of the use of value passing synchronisation can be found in the communication protocol example As an illustration, consider... lost, and, in this situation, the mediums notify the sender and receiver of this loss, which resend accordingly 6. 3 Examples 211 sustain themselves by eating and by (self-) reflecting on their theories However, they have no desire to subject their ideas to the competing views of their co-thinkers All philosophers have the same basic behaviour, which is coded in process phil process phil [pick, put] . expression into a sequence of binary compo- sitions would be equivalent up to strong bisimulation. 190 6 Beyond pbLOTOS 6. 1.4 Verbose Specification Syntax The top-level syntax for a bLOTOS specification. names. 192 6 Beyond pbLOTOS 6. 2 Full LOTOS As indicated earlier, full LOTOS integrates the constructs introduced above with a data typing notation, ACT-ONE. A complete presentation of this no- tation. development of verification tools for data passing calculi. 1 96 6 Beyond pbLOTOS send_0 send_1 Fig. 6. 2. Flattening of Data reassuringly, all theory developed in the pbLOTOS setting is still applicable in