Communicating Process Architectures 2002 (Concurrent Systems Engineering Series, 60)

Concurrent Systems Engineering Series Editors

M.R. Jane, J. Hulskamp, P.H. Welch, D. Stiles and T.L. Kunii

Volume 60 Previously published in this series: Volume 59, Communicating Process Architectures 2001 (WoTUG-24), A. Chalmers, M. Mirmehdi and H. Muller Volume 58, Communicating Process Architectures 2000 (WoTUG-23), P.H. Welch and A.W.P. Bakkers Volume 57, Architectures, Languages and Techniques for Concurrent Systems (WoTUG-22), B.M. Cook Volumes 54–56, Computational Intelligence for Modelling, Control & Automation, M. Mohammadian Volume 53, Advances in Computer and Information Sciences '98, U. Giidukbay, T. Dayar, A. Gursoy and E. Gelenbe Volume 52, Architectures, Languages and Patterns for Parallel and Distributed Applications (WoTUG-21), P.H. Welch and A.W.P. Bakkers Volume 51, The Network Designer's Handbook, A.M. Jones, N.J. Davies, M.A. Firth and C.J. Wright Volume 50, Parallel Programming and JAVA (WoTUG-20), A. Bakkers Volume 49, Correct Models of Parallel Computing, S. Noguchi and M. Ota Volume 48, Abstract Machine Models for Parallel and Distributed Computing, M. Kara, J.R. Davy, D. Goodeve and J. Nash Volume 47, Parallel Processing Developments (WoTUG-19), B. O'Neill Volume 46, Transputer Applications and Systems '95, B.M. Cook, M.R. Jane, P. Nixon and P.H. Welch Transputer and OCCAM Engineering Series Volume 45, Parallel Programming and Applications, P. Fritzson and L. Finmo Volume 44, Transputer and Occam Developments (WoTUG-18), P. Nixon Volume 43, Parallel Computing: Technology and Practice (PCAT-94), J.P. Gray and F. Naghdy Volume 42, Transputer Research and Applications 7 (NATUG-7), H. Arabnia Volume 41, Transputer Applications and Systems '94, A. de Gloria, M.R. Jane and D. Marini Volume 40, Transputers '94, M. Becker, L. Litzler and M. Trehel Volume 39, Transputer/Occam Japan 6, S. Noguchi, M. Ishizuka and M. Ota Volume 38, Progress in Transputer and Occam Research (WoTUG-17), R. Miles and A. Chalmers Volume 37, Parallel Computing and Transputers (ATOUG-6), D. Arnold, R. Christie, J. Day and P. Roe Volume 36, Transputer Applications and Systems '93, R. Grebe, J. Hektor, S.C. Hilton, M.R. Jane and P.H. Welch Volume 35, Transputer/Occam Japan 5 (OUGJ-5), S. Noguchi and M. Yamamoto Volume 34, Transputer Research and Applications 6 (NATUG-6), S. Atkins and A.S. Wagner Volume 33, Transputer and Occam Research: New Directions (WoTUG-16), J. Kerridge Volume 32, Networks, Routers and Transputers, M.D. May, P.W. Thompson and P.H. Welch Volume 31, Transputers and Parallel Applications (ATOUG-5), J. Hulskamp and D. Jones Volume 30, Transputing in Numerical and Neural Network Applications, G.L. Reijns and J. Luo Volumes 28 and 29, Parallel Computing and Transputer Applications (parts I, II), (Pacta '92), M. Valero, E. Onate, M. Jane, J.L. Larriba and B. Suarez Volume 27, Transputer/Occam Japan 4 (OUGJ-4), S. Noguchi and H. Umeo Volume 26, Transputers '92 - Advanced Research and Industrial Applications, M. Becker, L. Litzler and M. Trehel

ISSN: 1383-7575

Communicating Process Architectures 2002 Edited by

James Pascoe Department of Computer Science, The University of Reading, United Kingdom

Peter Welch Computing Laboratory, The University of Kent at Canterbury, United Kingdom

Roger Loader Department of Computer Science, The University of Reading, United Kingdom

and

Vaidy Sunderam Department of Mathematics and Computer Science, Emory University, United States of America

WoTUG-25 Proceedings of the 25th WoTUG Technical Meeting, 15–18 September 2002, University of Reading, United Kingdom

/OS

Press Ohmsha

Amsterdam • Berlin • Oxford • Tokyo • Washington, DC

© 2002, The authors mentioned in the Table of Contents All rights reserved. No part of this book may be reproduced, stored in a retrieval system, or transmitted, in any form or by any means, without prior written permission from the publisher. ISBN 1 58603 268 2 (IOS Press) ISBN 4 274 90539 X C3055 (Ohmsha) Library of Congress Control Number: 2002111139

Publisher IOS Press Nieuwe Hemweg 6B 1013 BG Amsterdam The Netherlands fax:+3120 620 3419 e-mail: [email protected]

Distributor in the UK and Ireland IOS Press/Lavis Marketing 73 Lime Walk Headington Oxford OX3 7AD England fax:+44 1865 75 0079

Distributor in the USA and Canada IOS Press, Inc. 5795-G Burke Centre Parkway Burke, VA 22015 USA fax: +1 703 323 3668 e-mail: [email protected]

Distributor in Germany, Austria and Switzerland IOS Press/LSL.de Gerichtsweg 28 D-04103 Leipzig Germany fax: +49 341 995 4255

Distributor in Japan Ohmsha, Ltd. 3-lKandaNishiki-cho Chiyoda-ku, Tokyo 101-8460 Japan fax:+813 3233 2426

LEGAL NOTICE The publisher is not responsible for the use which might be made of the following information. PRINTED IN THE NETHERLANDS

v

Contents Preface James Pascoe, Peter Welch, Roger Loader and Vaidy Sunderam Programme Committee

vii viii

Papers Semantics of prialt in Handel-C™ Andrew Butterfield and Jim Woodcock

1

Acceptances, Behaviours and Infinite Activity in CSPP Adrian Lawrence

17

HCSP: Imperative State and True Concurrency Adrian Lawrence

39

Consolidating the Agreement Problem Protocol Verification Environment James Pascoe and Roger Loader

57

On the Complexity of Buffer Allocation in Message Passing Systems Alex Brodsky, Jan Bcekgaard Pedersen and Alan Wagner

79

Java PastSet - A Structured Distributed Shared Memory System Kei Simon Pedersen and Brian Vinter

97

Synchronous Active Objects Introduce CSP's Primitives in Java Claude Petitpierre

109

Configurable Collective Communication in LAM-MPI John Markus Bjorndalen, Otto J. Anshus, Brian Vinter and Tore Larsen

123

Cache-Affinity Scheduling for Fine Grain Multithreading Kurt Debattista, Kevin Vella and Joseph Cordina

135

A Predicate Transformer Semantics for a Concurrent Language of Refinement Ana Cavalcanti and Jim Woodcock

147

Reconnetics: A System for the Dynamic Implementation of Mobile Hardware Processes in FPGAs Ralph Moseley

167

vi

Performance Analysis and Behaviour Tuning for Optimisation of Communicating Systems Mark Green and A li E. A bdallah

181

Configuration Discovery and Mapping of a Home Network Keith Pugh

191

Cluster Computing and JCSP Networking Brian Vinter and Peter Welch

203

View-Centric Reasoning for Linda and Tuple Space Computation Marc L. Smith, Rebecca J. Parsons and Charles E. Hughes

223

A Graphical Modeling Language for Specifying Concurrency based on CSP Gerald Hilderink

255

The "Honeysuckle" Programming Language: Event and Process Ian East

285

The "Honeysuckle" Programming Language: Object and Protocol Ian East

301

A Communicating Threads (CT) Case Study: JIWY Dusko Jovanovic, Gerald Hilderink, Jan Broenink

311

Prioritised Dynamic Communicating Processes - Part I Fred Barnes and Peter Welch

321

Prioritised Dynamic Communicating Processes - Part II Fred Barnes and Peter Welch

353

Implementing a Distributed Algorithm for Detection of Local Knots and Cycles in Directed Graphs Geraldo Pereira de Souza and Gerson Henrique Pfltscher

371

Author Index

387

vii

Preface Natural concurrency surrounds us. The concept is so prevalent that we interact and benefit from concurrent operations all the time and think nothing unusual of it. The simultaneous management of multiple tasks is how everyday business is conducted. Communication plays a paramount role in keeping things synchronised and, for sentient beings, happens without much pre-planning - it's automatic. However, for computers, it's not so easy. All computer systems contain concurrent architectures at many levels of their design. Over a long period, the WoTUG series of meetings have provided a major forum for the presentation and discussion of novel directions in the field of concurrency and communication. Communicating Process Architectures 2O02 extends this series by adding the high quality papers contained in these proceedings. The discussions are wide ranging and encompass many aspects of concurrent systems - from theoretical foundations, through software and hardware tools (including languages, libraries, kernels and processors) and on to applications. The 22 accepted papers will be presented in a single stream during the day, with (unplanned) fringe sessions in the evenings. Normal sessions will not concentrate on particular themes - except that closely related presentations will be kept together. The aim is to create a workshop athmosphere with all participants engaging in as much as possible, especially in talks that may appear to be outside their immediate interests. Selected papers will be invited for further development and submission to a (CPA) Special Edition of IEE Proceedings - Software, for journal publication in Spring 2003. Our best wishes and gratitude go to the authors for submitting their work and responding to the feedback provided by the referees. We also thank the CPA-2002 Programme Committee for their effort in reviewing the papers (and note that, where papers were submitted by members of that committee, they were reviewed in isolation with authors neither choosing nor knowing who their referees were). One individual deserves our special gratitude - Fred Barnes of UKC - without whose time andfiercesomecopy-editing, LaTeX and Word skills, these proceedings would have been in a much poorer state. Finally, we thank all the staff at Windsor Hall for their assistance in the local arrangements. This occasion is our Jubilee - the twenty-fifth in the series of WoTUG conferences and we intend to celebrate! They have consistently proven to be a valuable meeting place for all those interested in the problems and opportunities thrown up by parallel computing and concurrency. The participants reflect a wide spectrum of disciplines - theoreticians, software engineers, hardware engineers, tool builders and applications specialists. We meet in a relaxed, exciting, friendly and productive atmosphere ... often till very late the next morning ... the trick being to remember what was solved the night before ... and how we solved it! We like to thank you for your interest and welcome you to Reading. We very much hope you enjoy Communicating Process Architectures 2002 !! James Pascoe (University of Reading, UK) Peter Welch (University of Kent at Canterbury, UK) Roger Loader (University of Reading, UK) Vaidy Sunderam (Emory University, Atlanta, USA)

viii

Programme Committee Professor Peter Welch (Programme Chair), University of Kent at Canterbury, UK Dr. James Pascoe (Conference co-Chair), University of Reading, UK Dr. Roger Loader (Conference co-Chair), University of Reading, UK Professor Vaidy Sunderam (Conference co-Chair), Emory University, Atlanta, USA Dr. Alastair Allen, University of Aberdeen, UK Professor Hamid Arabnia, University of Georgia, Athens, Georgia, USA Richard Beton, Roke Manor Research Ltd., UK Professor Jan F. Broenink, University ofTwente, The Netherlands Dr. Alan Chalmers, University of Bristol, UK Professor Peter Clayton, Rhodes University, South Africa Dr. Barry Cook, University ofKeele, UK Ruth A. Ivimey-Cook, ARM Ltd., Cambridge, UK Gerald Hilderink, University ofTwente, The Netherlands Christopher Jones, BAES, Warton Aerodrome, UK Professor Jon Kerridge, Napier University, UK Dr. Tom Lake, InterGlossa, UK Dr. Adrian E. Lawrence, Loughborough University, UK Dr. Jeremy Martin, Oxagen Ltd., Oxford, UK Stephen Maudsley, Esgem Ltd, UK Professor David May FRS, University of Bristol, UK Dr. Majid Mirmehdi, University of Bristol, UK Dr. Henk Muller, University of Bristol, UK Professor Chris Nevison, Colgate University, New York, UK Professor Patrick Nixon, University of Strathclyde, Glasgow, UK Dr. Brian O'Neill, Nottingham Trent University, UK Dr. Roger Peel, University of Surrey, UK Professor Nan Schaller, Rochester Institute of Technology, New York, USA Professor G. S. Stiles, Utah State University, Utah, USA 0yvind Teig, Navia Maritime AS, Division Autronica, Norway Professor Rod Tosten, Gettysburg University, USA Dr. Stephen J Turner, Nanyang Technological University, Singapore Professor Paul Tymann, Rochester Institute of Technology, New York, USA Paul Walker, 4Links Ltd, UK Dr. Hugh Webber, Defence Evaluation Research Agency, Malvern, UK Professor Jim Woodcock, University of Kent at Canterbury, UK

Communicating Process Architectures - 2002 James Pascoe, Peter Welch, Roger Loader and Vaidy Sunderam (Eds.) IOS Press, 2002

Semantics of prialt in Handel-C™ Andrew BUTTERFIELD1 and Jim WOODCOCK2 1

Dublin University University of Kent at Canterbury [email protected] e 2

Abstract. This paper discusses the semantics of the prialt construct in HandelC[l]. The language is essentially a static subset of C, augmented with a parallel construct and channel communication, as found in CSP. All assignments and channel communication events take one clock cycle, with all updates synchronised with the clock edge marking the cycle end. The behaviour of prialt in Handel-C is similar in concept to that of Occam [2, 3], and to the p-priority concept of Adrian Lawrence CSPP[4]. However, we have to contend with both input and output guards in Handel-C, unlike the situation in Occam, although prialts with conflicting priority requirements are not legal in Handel-C. This makes our problem simpler than the more general case including such conflicts considered in [4]. We start with an informal discussion of the issues that arise when considering the semantics of HandelC's prialt construct. We define a resolution function (H) that determines which requests in a collection of prialts become active. We describe a few properties that we expect to hold for resolution, and discuss the issue of compositionality.

1 Introduction This paper discusses the semantics of the prialt construct in Handel-C[l], a language originally developed by the Hardware Compilation Group at Oxford University Computing Laboratory. It is a hybrid of CSP [5] and C, designed to target hardware implementations, specifically field-programmable gate arrays (FPGAs) [6, 7, 8, 9]. The language is essentially a static subset of C, augmented with a parallel construct and channel communication, as found in CSP. The type system has been modified to refer explicitly to the number of bits required to implement any given type. The language targets largely synchronous hardware with a multiple clock domains. All assignments and channel communication events take one clock cycle, with all updates synchronised with the clock edge marking the cycle end. All expression and conditional evaluations are deemed to be instantaneous, effectively being completed before the current clock-cycle ends. 1.1 Notation In Handel-C, a typical program fragment showing two pr ial ts in parallel might appear as: par { prialt a!11 b?x }; prialt b!22 c?y

{ : PI ; break ; : P2 ; break ; { : P3 ; break ; : P4 ; break ;

A. Butterfield and J. Woodcock I Semantics ofpri alt in Handel-C

Here, PI, P2, P3, and P4 denote the continuation code that gets executed if the corresponding guard is deemed to be active. In CSPP [4], this could be written as: ((a!ll

5 (blx - P 2 (x))) || ((W22 - P3) 5 (cly -» P 4 (j/)))

We adopt a simpler notation, in which we ignore the guard values, variables and continuation processes, viewing each prialt simply as a sequence of guards, and those prialts in parallel simply being collected into a set, to give:

/ (a!, 6?) We do this because the concern here is how the decision is made regarding which guards are deemed to be true. We are not interested in this paper in the consequent actions, both of the guard communications and the subsequent process actions. 1.2 The Problem The behaviour of prialt in Handel-C is similar in concept to that of occam [2, 3], and to the p-priority concept of Adrian Lawrence CSPP[4]. However, we have to contend with both input and output guards in Handel-C, unlike the situation in Occam. In relation to ppriority, Handel-C does not admit processes with conflicting priorities, so presents a simpler problem semantically, than that found in CSPP. The synchronous nature of Handel-C also makes it easy to establish what prialt statements are participating in a synchronisation event at any given point in time. A particular consequence of this is that all the key events are deemed to occur simultaneously. Our interest is in determining the outcome when a number of prialts are simultaneously ready to run, i.e the outcome of the following situation:

k

(9nl,9n2,---,9nj,---,9nmn)

,

The guards can have only one of the following two forms: input guard c? or output guard c!. Handel-C allows the use of a def aul t guard as the last guard in a pr ial t, but again this is something which we will ignore for current purposes. Another constraint present in Handel-C is that a channel may appear only once in any given prialt. Handel-C also admits communication statements outside of pr ial ts ("naked communication"). However these can be modelled by a singleton pr ial t with a null continuation process: c!e

=

prialt{c!e:break}

In CSPP, semantics is given using Acceptances which are partial functions from traces to relations between sets of of offered and accepted events, where the domain of a partial function equals the set of traces of the process it denotes. A process is therefore described by describing how, after any of its traces (s), with an environment offering a set of events (E), it is willing to accept a specific set (A) of events. The notation used for this is s : £~~> A

A. Butterfield and J. Woodcock I Semantics ofprial t in Handel-C

3

However, in Handel-C, it seems to make more sense to view the prialts as making specific offers of sequences of events, rather than sets of events. We can view the prial t statement: ( g i , g - z , . . . , gn} as offering the events gi,g2,...,gnin that order. In effect what we have done here is to abstract the prial t notation to reflect precisely the prioritised list of events that it is willing to offer/accept. A general resolution mechanism then determines which events actually occur. This paper is a description of the formal semantics of that resolution mechanism, in a form sufficiently general that it can be incorporated into a variety of different semantics for HandelC—denotational [10], operational [11] or otherwise. As prial t resolution in Handel-C is deterministic, having the form of a total function from sets of prialts to their resolution, we adopt a formal notation most suited to describing functions, that of the "Irish School" of the VDM (VDM*) [12]. This can be described briefly as a functional subset of standard VDM (VDM-SL [13]), using equational reasoning rather than the logic of partial functions. A notation guide is provided as an appendix, as well as by explanations running through the text. Despite the Handel-C language's superficial similarity to CSP, we did not adopt CSP as a semantic modelling language here, because it lacks any notion of priority. Also, it was not clear when the work started if it is possible to capture this at all in CSP. Clear evidence for this is the work of Adrian Lawrence [14, 4, 15], which requires extensions to CSP in order to capture the notion of priority, and simultaneous events.

2 Informal Description We start with an informal discussion of the issues that arising when considering the semantics of Handel-C 's prial t construct. We consider the situation where we have n prial t statements which are to be resolved, and we assume, as already stated, a simplified model where prialts consist solely of the communication statements, hereinafter called requests. Each prialt is therefore a nonempty sequence of requests. We assume all prialts are well-formed, in that any given channel identifier occurs at most once in any given pr ial t. 2. 1 Priority: Absolute or Relative ? Initially, with Handel-C, it was assumed that a prial t of the form

assigned priority levels 1, 2, . . . m to guards g\, g%, . . . gm respectively. However all attempts to reconcile this absolute priority view with Handel-C's actual behaviour resulted in failure. After experimenting with prialts in Handel-C it became very clear that the notion of absolute priority was completely incorrect. Instead, each prialt simply defines a relative priority for the channels to which it refers. This is a strong indicator that p-priority, rather than e-priority [14], is the correct way forward. Merging the (locally total) ordering for each pr ial t results in either an overall partial order, or a relation with cycles. In the former case we use the ordering to determine the successful requests. In the latter case Handel-C reports an error. The simplest example of this is {(a!, 6!}, (6?, a?)} In [4], provision is made to give a meaning to this expression, but in Handel-C, which is deterministic, this is an un-recoverable compile-time error. If we try to resolve this in the

4

A. Butterfield and J. Woodcock / Semantics ofpri alt in Handel-C

Handel-C semantics by nondetenninistically choosing to "break" cycles, we end up losing some nice laws regarding the sequencing in pr ial ts and the way in which an offered event masks all subsequent events in a given prialt: (pi, . . . , & , . . . 0m) = (0i, . . . , &) when gt is "offered" This law does not hold if we resolve priority conflicts by breaking priority cycles. 2.2 Deriving Channel Partial Ordering Given prialts, we first take each constituent prialt and convert it into the corresponding relation (total linear ordering). We then merge all the relations together, one from each prialt, using relational union, and take the transitive closure to get one big relation (p). This relation captures the priorities between all participating channels. We then examine the (graph of) the relation for cycles. If present, we should flag an error condition at this point—the processes involved all diverge. If there are no cycles, then we have a partial ordering on all the channels which can then be used as the basis for determining the successful requests. Also this relation will in general have many minimal elements. At this stage we have all the prialts, and an induced partial ordering on the channel identifiers. We identify active channels (offered events) as being those which appear at least twice in (different) prialts, with complementary directions. 2.3 Pathological Cases Note that a channel may occur multiple times, in multiple prialts. This is satisfactory as long as all but two complementary requests for that channel are effectively masked by other channels with requests at higher priority. An example is:

which is equivalent to: {, (,, In the event that we have one writer to a channel and multiple receivers, as in

the outcome (assuming all these channel instances are deemed active) is that each reader gets their own copy of the single written value. What happens in the case of multiple writers ?

In Handel-C Version 2.1 [16], the compiler flagged this with a warning, and in simulation, the value obtained from the channel was the bitwise logical-OR of the underlying representations of all the inputs ! It is clear that a multiplexor (which ends with a logical OR gate) is getting multiple input streams switched through simultaneously to the output. This is bizarre, but at least the compiler (i) informed the user and (ii) maintained the order independence of parallel composition of prialts: Pi II ^2 = Pi II Pi However, in Handel-C Version 3.0 [1], the compiler supplies no warning at all, and proceeds to accept data for the channel write occurring in the prialt which is first in the program text ! This means that { (c?:r), , (c!22) } £ { (c?rr), (c!22),

A. Butterfield and J. Woodcock / Semantics ofpri alt in Handel-C

5

The first writes 11 to x, the second writes 22 ! To handle this properly, we would have to talk about sequences of prialts being resolved, rather than sets. Also we would have to sacrifice the following very nice property of Handel-C (which was true for 2.1, but is now false for 3.0): P, || P2 = P2 || A We shall not concern ourselves overly with this case, but rather consider such programs at present to be ill-formed, with no obligation on our part to supply a formal semantics for them. They should certainly not be the result of any refinement methodology for calculating Handel-C programs from specifications, which is the ultimate goal of this work. 2.4 Identifying Active Channels Once we have identified the minimal active channels and removed them and the prialts in which they appear, we repeat the entire process of constructing the ordering afresh, and selecting the minimal active channels, with the remaining prialts. We continually repeat this until no further changes occur.

3 Formal Treatment We are defining a resolution function (72.) that determines which requests in a collection of prialts become active. 3.1 Input Types We start by considering as given a collection of channel identifiers: c € Ch

With every I/O request in Handel-C there is an associated direction: d <E Dir = {IN,OUT} This allows us to define an input-output request as a channel/direction pair: Request:

r € Req = Ch x Dir These "requests" are in fact our guards, as all such guards in Handel-C are of this form. In general we shall write c! and c? as shorthands for (c, OUT) and (c, IN), respectively. Having abstracted away from the details of the processes that are guarded in prialts, we view them as sequences of requests, where each channel occurs at most once: p e PriAlt = Req+ inv-PriAlt(a) = (# o elems o 7Ti*)cr = len cr The notation inv-PriAlt is the VDM* notion of "invariant", which gives a boolean expression defining which elements of the space are considered well-formed, which is analagous to the "healthiness conditions" of CSP/CSPP. What we are resolving is simply a set of pr ial ts: P € PriGrp = PPnAlt This structure is the input to our resolution process.

6

3.2

A. ButterGeld and J. Woodcock I Semantics ofprialtin Handel-C

Output Types

We now consider the information that needs to be output from the resolution process. Firstly, we need to know which channels are going to be active, i.e. able to communicate. We need to know the prial ts with which these channels are associated, so we can identify the specific guards involved, and consequently which guarded processes will be involved. We cannot determine this information from knowledge of which channels are active alone, because a given channel can be active in a proper subset of those pr ial ts in which it is mentioned. To see this, consider the following prialt collection, including guarded processes, (ignoring directions, with prial ts labelled for ease of reference):

2 : (a -» P3) 3 : 6 -> P4 4 : b -> P5

Here, both events a and b will proceed. Event a will involve prialts 1 and 2, leading to the subsequent execution of PI and P3. Event b will involve prialts 3 and 4, leading to P4 and P5 being activated subsequently. However, even though prialt 1 mentions 6, and 6 takes place, it is masked by the higher priority a event in that pr ial t, which is also active. Hence we need to couple a channel (event) identifier with the prialts which are actually involved. Our key output structure is therefore a map from channels to prial t-sets: 7 e CPMap = Ch -> PriGrp In the example above, we expect to see an output of / {a -> { (a -» Plt 6 -> P2), (a - P3) }} I {b~{(b^P4),

We can then determine the active processes by using the channel value as a lookup key in the associated set of prialts. So, for

we perform a lookup of a in both (a —> P! , 6 —> P2) and (a —» P3) to get PI and P3 respectively. Of course, in this paper we are ignoring the guards processes P, mentioned in this example, but at least this example shows in principle how that information can be incorporated. A key aspect highlighted by this example is a well-formedness constraint on channelprial t-set pairs. We expect the channel component to be present in every prial t in the corresponding set: inv-CPMap : CPMap -» B inv-CPMap 7 = Vc e dom 7 • inv-CPSet~,(c) inv-CPSet-,(c} = V/o € 7(0) • c e (elems o n^)p

A. Butterfield and J. Woodcock / Semantics ofpri alt in Handel-C

3.3

Intermediate Types

In order to describe the resolution process, it will be necessary to have some key intermediate structures. Firstly, we note that the input to the resolution process is very pria It-centric, but that it will be helpful to have a structure that is more channel-centric. Each channel present occurs at most once in any given prialt, in association with a corresponding direction. With any given channel, over all the prialts in which it appears, we would like to associate the directions of the corresponding requests. We therefore map each channel to a set of the request directions associated with it: K € ChReqs = Ch ->• IPDir As described above, we need build a relation over channels. We choose to model relations here as set- valued functions, as is conventional in VDM*: •R € ChRel = Ch -> PCh This formulation, while not very conventional outside VDM*, does make it very easy to extract the minimal elements, which denote the channels of highest priority. 3.4

Intermediate Operators

We now look at some operators for our intermediate semantic domains. We start with a function that converts the input of pr ial t sets into a channel request mapping: PriGrp —* ChReqs

o i*))P

Basically every entry p in P of the form

((ci.d.M^flfe),...,^,^)) is converted to an entry of the form {Ci i-» { d{ }, C'2 •-> { (I? }, . . - , Cfe i-> { 4

}}

All of these (one for each p 6 P) are then joined together using Q to provide one relation. The Q operator is a lifted (indexed) form of union, and has the effect of acting as relational union. In particular, we get

Once we have this channel request mapping, it becomes very easy to see if any channel is active. We simply look it up, and deduce that the channel is active if both directions are present: Act : ChReqs -» Ch -» B ActKc = K(C) = {IN, OUT}

8

A. Butterfield and J. Woodcock I Semantics of pr i a 1 1 in Handel-C

The central intermediate structure is that which captures the partial ordering on channel priorities induced by the collection of prial ts. Consider the following input structure:

For each sequence in P, we then discard the direction data (TTI*), and then convert the resulting sequence into the corresponding total ordering relation (using order), modelled as a set valued mapping, but shown symbolically here:

S' =

{ C.-1 -< Cj2 -< ----
K(P\ U P2) = (71 U 72- #1 U B2)

A. Butterfield and J. Woodcock I Semantics ofprial t in Handsl-C

13

5 Compositionality of prialt In order to achieve full compositionality, we need tofindan operator | such that

This property is necessary in order to provide a denotational semantics, and makes it much easier to produce a set of useful laws for reasoning about Handel-C programs. It turns out that this is very easy to achieve, at least in a technical sense. Given the output of a resolution, we can use pAltOf to give us the original input data, so we can define \ as: (7', P'} | (<J', Q') =ft(pAltOf(V,P') U pAltOf({ (a!, &? = ({{ (a?, c?>,(d)}},0)

However, when we combine P and Q:

we find the channel a is now active, and removing its prialts from the pool results in channels b and c being inactive, when the leftover pr ial ts are considered: K(P U Q) = ({a ^ { R 6?}, (a?, c?) }}, { 0. More precisely

where S is the set of all events. 5.4 Termination: / and Sfap The processes illustrated above simply cease activity, but useful processes normally terminate. That is how a process passes control to a successor on successful completion. In CSP this is done with a special token written as /. An associated process is Skip which has a single behaviour which does nothing except terminate:

In CSPP / has a special status: it cannot be offered to an event, and it cannot appear in a trace. In classical CSP, / is treated as an ordinary event for most purposes so it may appear in traces. To do this consistently requires considerable ingenuity and awkwardness in Failures semantics. These problems do not arise in Acceptance semantics. A characteristic property of / is (a -»- Skip) § (b -> Skip) = (a -> b -* Skip) This has a behaviour with (ab) : X -

The / which passes control from a —*• Skip to b —> Skip is a hidden synchronisation between the two processes, and does not appear in the trace: rather it is associated with the instance of the sequential constructor | which "glues" the two processes together.

26 5.5

A.E. Lawrence / Acceptances, Behaviours and Infinite Activity Recursion: // P • a —» P

CSP includes solutions to recursive equations like

Q = a-+Q . which defines an infinite process. This can be written Q = nP*a-*P liP • f(P) denotes denotes the unique solution of the equation P = f(P) if one exists. If there is more than one solution, then it selects the least, that is the most non deterministic, of the available solutions, if any. Determining under what conditions such solutions exist is one of the primary tasks in setting up a denotational semantics for any CSP variant. Acceptance semantics based on behaviours shows that CSPP constitutes a complete metric space. This shows that all functions/ which are contracting with respect to that metric have unique solutions. With the addition of a 'miraculous' T process, CSPP is also a complete lattice and therefore also a complete partial order. The order relates processes with common behaviours where those that are more deterministic are 'better than' those which exhibit more internal choice. This refinement order is defined below. It then follows from standard results about fixed points that all sensible recursions in CSPP have 'best' - most deterministic - solutions. Be that as it may, note for the moment that p,P • a —» P is an infinite process with traces consisting of a sequence of a's. Its semantics is

(a") : X ~* {a} n X where (a") is a trace of n consecutive a's. It is unbounded: it can perform more than n events for any n. This is our first example of a behaviour with an infinite domain. The domain is the set of all finite traces consisting of sequences of as. This ability to represent infinite behaviour using only finite traces is simple, yet significant. It is the extra layer of structure at the individual behaviour level that yields the expressive power to distinguish truly infinite behaviour. 5.6 Hiding, divergence and/: (a —> b —» Stop) \ {a} An important feature of CSP is that it includes hiding. An example: (a -» b -» Stop) \ {a} = b -» Stop. So a becomes an 'internal event' invisible to the environment. This is the primary abstraction mechanism. It introduces nondeterminism and divergence. So (a^(lMp.b^p))\{b},

(1)

is a process which performs a, but then goes into an infinite loop which no longer interacts with its environment, and there is no way to exercise control. This livelocked process is said to be divergent in analogy with uncontrolled infinite behaviour. Such situations are captured with the aid of another pseudo-event X. The notation is intended to indicate undesirable non-terminating behaviour contrasting with /. For equation (1) the behaviour is: () : X ~» {a} n X (a): X -» {X}.

A.E. Lawrence /Acceptances, Behaviours and Infinite Activity

21

When priority is present, processes like ((a -> Stop)H(b -> Stop)) \ {a} = Stop, arise, (a —> Stop) D (& —* Stop) is a process which always performs a when it is available, but otherwise performs b. But ((a -> Stop) D (6 -». Stop)) \ {a} = Stop n (fc -» Stop). Here (a —» Stop) O (6 —> Stop) treats the events a and b on an equal basis. Both of the above equations are true in the semantics presented below. 5.7

External choice: (a —* Stop) n (b —> Stop)

A simple example of external choice is, (a —> Stop) D (& —* Stop). It is a process which is partly controlled by the environment as we can see in bi:: 62 ::

{} : X ~» {a, £} H X {) : X ~» {a} * a € X *• {fc} D X

X ~» {b} + b € X > {a} D X X -» {&} : X ~+

(2)

0 0.

EI •« boolean *• E2 is a notation borrowed from CSP itself: if the boolean is true the result is the expression E\, otherwise it is E^. Our process is nondeterministic because there are in general three possible responses to an initial offer of X. The last two lines in equation (2) represent the responses common tobl,b2 and b3. bl :: () : {a, b} ~-> {a} shows that the process may choose to perform the event a when given a choice between a and b. But suppose that we have a process which is compliant in the sense that it wishes to conform to the selection made by a parallel partner in its shared environment. It expresses that by responding with both a and b: bl :: {) : {a,b} -^ {a,b}. Thus D allows any of these possibilities: it abstracts from those details. Priority is a means of choosing just one class of these behaviours. 5.8

The pseudo even ts { /, X}

/ and A model termination and livelock respectively. We work with a global alphabet E U {/, X} where S is a set which includes all the 'ordinary' events that may arise. Later we will encounter the odd process Skip D div. It always accepts {/,/}. That is X —•» {/, X} for every offer X. {/,X} has the form of a compliant response, but since an environment can only offer real events, it cannot 'select' between / and X: there is no way to make Skip D div comply with a request to terminate because the environment has no way of making such a request. How then does Skip D div differ from Skip n div? The acceptance semantics certainly differ. The first has a single compliant behaviour; the second two deterministic behaviours. The nondeterminism in Skip F! div is between the two possible behaviours. We interpret any unresolved compliance also as a nondeterministic outcome. So Skip D div is deterministic in that there is only one behaviour, but nondeterministic in that no environment can choose between / and X in the response of that behaviour. So no single experiment can distinguish Skip D div and Skip n div.

28

5.9

A.E. Lawrence I Acceptances, Behaviours and Infinite Activity

Interleaving: (a -> Stop) \\\ (b -+ Stop)

The interleaving (a —> Stop) 1 1 1 (£ —»• Stop) has 3 behaviours characterised by bl::():

X ~»

bl : : ( ) : X

{a,b}DX

~» {a} 4 a € X »> {ft} DX

6 3 : : { ) : X ~*

{fc} {a} D X

X -» {a} n X X -~» 0 X -» 0 ,

where the responses after the first event for a particular trace are common. This is just (a -> fc -> Stop) n (b -» a -> Stop) , so the process is prepared to perform a and fe in either order. And when offered {a, b} it may choose a, b or be noncommittal. 5.10 Parallel: (a -» Stop) || (a -» fe -» Stop) {«} (a —» Stop) || (a —> fc —»• Stop) is a process that synchronises on the event a. The two {} component processes can only engage in a simultaneously so there is only one behaviour given by:

{) : X -» {a}nX (a) : X -» {fc} n X (ab) : X

-» 0 .

ft is an independent event, so one partner caa engage in it without the participation of its compatriot. So (a -» Stop) || (a -> ft -* Stop) = (a -* fc -» Stop) .

6 Alphabets and traces As above, there is an alphabet S of ordinary events: this will be large enough to include all the visible events of any process that we need to describe. To this we add the pseudo events / and X, writing S/x = S U {/,*}. Traces are sequences, empty or finite, of events drawn from E. () is the empty sequence. The set of all finite traces drawn from S is written as E* . The acceptance semantics here based on behaviours needs only finite traces. 7

Behaviours

We specify the meaning of a process by describing its responses after it has performed some trace of events. Traces are members of E* . Given such a trace, we then specify an acceptance function as {X ~» U}. The offer X is some subset of the alphabet E: that is X C E. And

A.E. Lawrence / Acceptances, Behaviours and Infinite Activity

29

a response U is a subset of I/*. So there is a partial function b : £* -+* (PE representing each possible behaviour. Thus we have a description which is a set BPof such behaviours: *PS / X ))

(3)

[[P J is the usual notation for the semantic function describing the behaviour of the process P, but BP is more intuitive and used here. The set of traces of the process is just the union of the traces of the behaviours: traces(P) = \J{traces(b) \ b e BP} , where traces(b) = dom b. We sometimes identify a process directly with its behaviours where the context warrants. And that leads to a simple matching normal form. 8

p-priority

CSPP extends CSP with extra operators including D and || . 8.1

Process Priority and external choice.

P = PI DP2 extends external choice and provides a semantics for PRI ALT in occam. The first event is selected in favour of PI. So Pa& = (a —>• Stop) D (b —> Stop), with a minimal alphabet S = {a, b} for simplicity, has the behaviour: : {):

(a): (b):

{«,&} - H {a} - {a}

X X

-» 0 -> 0

.

PI D PI is the symmetrical version. So the behaviour of P = (a —* Stop) D (b —> Stop]

is: {) : {}: (}••

{a,b} ~» {a, 6} {«} - {a} \b} - {*}

{} : (a) :

0 -» 0 X -» 0

(b):

X -0

5)

W

P! D P2 embodies the antithesis of p-priority in that it refuses to choose between a and b but rather treats them symmetrically. But it will always respect the p-priority of a parallel partner. 9 Fairness The presence of priority in CSPP provides a way to express degrees of fairness. Since infinite behaviour is also captured properly, this includes eventual fairness.

30

A.E. Lawrence I Acceptances, Behaviours and Infinite Activity

If A = up • a —»• p and B = up • b —» p, consider P\ = A \\\ B where there are no other processes involved so that both component processes are always ready. Then an implementation of PI can always favour A over B, that is A \ \ \ B I) PI , and no b is ever performed.

VbeBP* Vs & traces(b) • VX, Y C E • bsX = 0 A Y C X =» bsY = 0 A bsX n Y ^ 0 =» bsY ^ 0

If an offer can be accepted, then smaller offers including accepted events can also be accepted: bsX n 7/x ^ 0 A Y C X

Combining conditions from H4 and H5 shows that all behaviours b & BP have acceptances which obey (Cl)

(C2) (C3)

bsX = 0

fex

A Y C X =» for = 0

fexny^0 => ^F^0 n y/x ^ 0 A F c x

when ^ is one of their traces and X and Y C S. These requirements for any individual behaviour & are collected in the following abbreviation.

32

A.E. Lawrence I Acceptances, Behaviours and Infinite Activity

Definition 12.1 behave (b) is an abbreviation for A {) € domfc

A Vs e dom(fe) • VX C E • bsX C X'* A

VseE* «VjceE« (x) € dom(6) A K C X =*

foy

=0 foF^0

A A

13 Semantics There is only room here to give the precise semantics for some of the simpler cases and to highlight refinement and recursion. In particular, the definition of the parallel operators requires a little technical infrastructure which we omit. 13.1 Stop {} : X - 0

(6)

The only behaviour has a single empty trace and no events are accepted. This means BStop = {{{} -» {X - 0) | X C E}}} ,

(7)

so the only behaviour b has domain {{)} = traces(b) and b()X = 0 for every X C £. 13.2 Skip {):X~*{/} (8) Again there is only one behaviour, the only trace is empty, but the process always offers to terminate. BStip = {{()~ AX •{/}}} (9) 13.3 div

We define a simple div here. It is a process which immediately livelocks: 0 : X - {A}

There is a single behaviour {{} i-» AX • {X}}. 13.4 _L

J_ is the most unpredictable of processes: it includes every behaviour.

B_L = {fc | behave(fc)}

A.E. Lawrence / Acceptances, Behaviours and Infinite Activity

33

13.5 T

T is a miracle. And a fraud. It has no behaviours, and so is not implementable. But it refines every process. And ensures that every monotone recursion is well defined.

13.6

Prefix choice

Consider e : £ —> P(e] with E C E. In general there are many possible initial behaviours b:: {} : X ~ * 0 - « X n £ = 0 * U

where U C X n £ is not empty. So b() must satisfy b()X = 0 when X n £ = 0 and C X n £ otherwise; (£?:£-»/>(