Concurrency Intuition and Formal Verification Yes We Can

Concurrency, Intuition and Formal Verification: Yes, We Can! a b Matt Pedersen and Peter Welch a School of Computer Science, UNLV, USA b School of Computing, University of Kent, UK phw@kent. ac. uk matt@cs. unlv. edu Curricula for Concurrency and Parallelism SPLASH 2010, 17 th. Oct 2/20/2021 Copyleft (GPL) P. H. Welch and J. B. Pedersen 1

A Thesis (for which we have experimental evidence) Not only can we (and should we) teach concurrency at the start of the undergraduate CS curriculum … But also we can (and we should) teach formal analysis and verification of this concurrency at the same time … 2/20/2021 Copyleft (GPL) P. H. Welch and J. B. Pedersen 2

A Thesis (for which we have experimental evidence) Not only can we (and should we) teach concurrency at the start of the undergraduate CS curriculum … Because it’s there Because it scales Because it simplifies Process Orientation for complexity CSP / π-calculus occam-π / JCSP 2/20/2021 Copyleft (GPL) P. H. Welch and J. B. Pedersen for performance 3

A Thesis (for which we have experimental evidence) Not only can we (and should we) teach concurrency at the start of the undergraduate CS curriculum … Because it’s there Sequence, variables, assignment, parameters, concurrency, channels, synchronisation, … Fundamental primitives of software engineering All are important. All are simple. All are available. 2/20/2021 Copyleft (GPL) P. H. Welch and J. B. Pedersen 4

A Thesis (for which we have experimental evidence) Complex and high-performance systems cannot avoid concurrent design, implementation and reasoning. Common concurrency bugs are intermittent – not repeatable on demand. Untestable in practice. We stand on the shoulders of giants (who made theory and model checkers). We verify programs just by writing programs … it becomes everyday practice. But also we can (and we should) teach formal analysis and verification of this concurrency at the same time … 2/20/2021 Copyleft (GPL) P. H. Welch and J. B. Pedersen 5

Example: autonomous robot component The following example has been developed from one first worked through in a single lesson of a graduate class in concurrency at UNLV in the spring of 2010. 2/20/2021 Copyleft (GPL) P. H. Welch and J. B. Pedersen 6

Example: autonomous robot component a 0 b 0 c 0 a 1 b 1 c 1 d 0 d 1 The following example has been developed from one first worked through in a single lesson of a graduate class in concurrency at UNLV in the spring of 2010. Device : real-time controller for 8 channels (4 input, 4 output). 2/20/2021 Copyleft (GPL) P. H. Welch and J. B. Pedersen 7

Example: autonomous robot component a 0 b 0 c 0 a 1 b 1 ask P 0 P 1 c 1 d 0 ping d 1 P 2 ans Device bar Device : real-time controller for 8 channels (4 input, 4 output). There are 3 sub-components: P 0 (weapons systems), P 1 (vision processing) and P 2 (motion stabilizer). They exchange information over internal channels (ask, ans, ping) and all coordinate actions with an internal barrier (bar). 2/20/2021 Copyleft (GPL) P. H. Welch and J. B. Pedersen 8

Example: autonomous robot component a 0 b 0 c 0 a 1 b 1 ask P 0 P 1 c 1 d 0 ping d 1 P 2 ans Device bar CSP semantics apply. Channel communication is unbuffered (sender waits for receiver and vice-versa). Any process reaching a barrier waits for all processes to reach the barrier. They exchange information over internal channels (ask, ans, ping) and all coordinate actions with an internal barrier (bar). 2/20/2021 Copyleft (GPL) P. H. Welch and J. B. Pedersen 9

ask P 0 P 1 ping P 2 ans Device 2/20/2021 bar Copyleft (GPL) P. H. Welch and J. B. Pedersen © 2003 Hasbro and Takara. Tomy 10

Behaviour: two representations a 0 b 0 c 0 a 1 b 1 ask P 0 P 1 c 1 d 0 ping d 1 P 2 ans Device bar occam-π: for compiling to a runnable system. [memory overheads <= 32 bytes per process / synchronisation overheads of order tens of nanoseconds / eats multicore nodes for breakfast. ] CSP: formal analysis. [FDR 2 model checker + other (simple) formal reasoning. ] 2/20/2021 Copyleft (GPL) P. H. Welch and J. B. Pedersen 11

Behaviour: two representations a 0 b 0 c 0 a 1 b 1 ask P 0 P 1 c 1 d 0 ping d 1 P 2 ans Device bar g to n i p p occam-π: for compiling to a runnable system. a ve m i t c e j n i noverheads an / synchronisation e [memory overheads <= 32 bytes c per process s e a w t h e s b ti gfor breakfast. ]m n i a/neats t f i m h e s s of order tens of nanoseconds multicore nodes o / e r l f x b y a u l t l o n r a t y c i s at π ittle l m o d t a u h a s occam. P. S C m dent o e u t o t r a s r s e u cla gen e o h t t SP. O s C n t i s i x use l eanalysis. r CSP: formal o o o f t y A d. m rea e t h e t y t o n + other (simple) formal reasoning. ] [FDR 2 model checker … π m a occ 2/20/2021 Copyleft (GPL) P. H. Welch and J. B. Pedersen 12

Behaviour: what are we looking for? a 0 b 0 c 0 a 1 b 1 ask P 0 P 1 c 1 d 0 ping d 1 P 2 ans Device bar deadlock: might it ever stop? [e. g. P 0 and P 2 want to synchronise on bar, but P 1 wants to ping. ] livelock: might it get busy … but refuse all external signals? [e. g. P 0, P 1 and P 2 start engaging in an infinite sequence of internal channel or barrier synchronisations (on ask, ans, ping and bar). ] 2/20/2021 Copyleft (GPL) P. H. Welch and J. B. Pedersen 13

Behaviour: what are we looking for? a 0 b 0 c 0 a 1 b 1 ask P 0 P 1 c 1 d 0 ping d 1 P 2 ans Device bar safety: might it ever engage in an incorrect sequence of external signals? liveness: will it engage in correct sequences of external signals, as required? [Some specs allow alternative sequences to be performed – all are correct, but an implementation must only do one and is free to choose. ] 2/20/2021 Copyleft (GPL) P. H. Welch and J. B. Pedersen 14

Behaviour: occam-π (executable) a 0 b 0 c 0 a 1 b 1 ask P 0 P 1 c 1 d 0 ping d 1 P 2 ans Device bar es u l a v a t da , e l p m y e xa h e t , s i y t h i t in plic s i m i s s y l r a o n ra t. F nt u n e t o i a n v v o a e l c h e be tr ge For the utations are no with all messa p s, e m d o o c c d e n s a he t n i d e t t are omi o. r e z o t ted c a r t s b a 2/20/2021 Copyleft (GPL) P. H. Welch and J. B. Pedersen 15

Behaviour: occam-π (executable) a 0 b 0 c 0 a 1 b 1 c 1 ask P 0 P 1 d 0 d 1 ping P 2 ans Device PROC P 0 (CHAN INT WHILE TRUE INT x, y, z: SEQ ask ? x a 0 ? y ans ! 0 b 0 ? z SYNC bar c 0 ! 0 : 2/20/2021 bar a 0? , b 0? , c 0!, ask? , ans!, BARRIER bar) -- take question -- return answer (will depend on x and y) -- wait for the others Copyleft (GPL) P. H. Welch and J. B. Pedersen 16

Behaviour: occam-π (executable) a 0 b 0 c 0 a 1 b 1 ask P 0 P 1 c 1 d 0 d 1 ping P 2 ans Device bar PROC P 1 (CHAN INT a 1? , b 1? , c 1!, ask!, ans? , ping!, BARRIER bar) WHILE TRUE INT x, y, z: SEQ ask ! 0 -- ask question ans ? x -- wait for answer a 1 ? y b 1 ? z SYNC bar -- wait for the others c 1 ! 0 ping ! 0 -- update neighbour : 2/20/2021 Copyleft (GPL) P. H. Welch and J. B. Pedersen 17

Behaviour: occam-π (executable) a 0 b 0 c 0 a 1 b 1 c 1 ask P 1 P 0 d 1 ping P 2 ans Device PROC P 2 (CHAN INT WHILE TRUE INT x: SEQ SYNC bar d 0 ! 0 ping ? x SYNC bar d 1 ! 0 ping ? x : 2/20/2021 bar d 0!, d 1!, ping? , BARRIER bar) -- wait for the others -- receive update Copyleft (GPL) P. H. Welch and J. B. Pedersen 18

Behaviour: occam-π (executable) a 0 b 0 c 0 a 1 b 1 ask P 1 P 0 c 1 d 0 d 1 ping P 2 ans Device bar PROC Device (CHAN INT a 0? , b 0? , c 0!, a 1? , b 1? , c 1!, d 0!, d 1!) CHAN INT ask, ans, ping: BARRIER bar: PAR ENROLL bar P 0 (a 0? , b 0? , c 0!, ask? , ans!, bar) P 1 (a 1? , b 1? , c 1!, ask!, ans? , ping!, bar) P 2 (d 0!, d 1!, ping? , bar) : 2/20/2021 Copyleft (GPL) P. H. Welch and J. B. Pedersen 19

Informal Intuitive Behaviour: occam-π (executable) PROC P 0 (CHAN INT a 0? , b 0? , c 0!, ask? , ans!, BARRIER bar) PROC P 2 (CHAN INT d 0!, d 1!, ping? , WHILE TRUE BARRIER bar) INT x, y, z: WHILE TRUE SEQ INT x: ask ? x -- take question SEQ a 0 ? y SYNC bar -- wait for others ans ! 0 -- return answer d 0 ! 0 b 0 ? z ping ? x -- receive update SYNC bar -- wait for others c 0 ! 0 d 1 ! 0 : ping ? x -- receive update : PROC P 1 (CHAN INT a 1? , b 1? , c 1!, ask!, ans? , ping!, BARRIER bar) WHILE TRUE INT x, y, z: SEQ ask ! 0 -- ask question ans ? x -- wait for answer a 1 ? y b 1 ? z SYNC bar -- wait for the others c 1 ! 0 ping ! 0 -- update neighbour : 2/20/2021 Copyleft (GPL) P. H. Welch and J. B. Pedersen What patterns of external (blue) signalling are possible from Device? 20

Informal Intuitive Behaviour: occam-π (executable) PROC P 0 (CHAN INT a 0? , b 0? , c 0!, ask? , ans!, BARRIER bar) PROC P 2 (CHAN INT d 0!, d 1!, ping? , WHILE TRUE BARRIER bar) INT x, y, z: WHILE TRUE SEQ INT x: ask ? x -- take question SEQ a 0 ? y SYNC bar -- wait for others ans ! 0 -- return answer d 0 ! 0 b 0 ? z ping ? x -- receive update SYNC bar -- wait for others c 0 ! 0 d 1 ! 0 : ping ? x -- receive update : PROC P 1 (CHAN INT a 1? , b 1? , c 1!, ask!, ans? , ping!, BARRIER bar) WHILE TRUE INT x, y, z: SEQ ask ! 0 -- ask question ans ? x -- wait for answer a 1 ? y b 1 ? z SYNC bar -- wait for the others c 1 ! 0 ping ! 0 -- update neighbour : 2/20/2021 Copyleft (GPL) P. H. Welch and J. B. Pedersen What’s first? 21

Informal Intuitive Behaviour: occam-π (executable) PROC P 0 (CHAN INT a 0? , b 0? , c 0!, ask? , ans!, BARRIER bar) PROC P 2 (CHAN INT d 0!, d 1!, ping? , WHILE TRUE BARRIER bar) INT x, y, z: WHILE TRUE SEQ INT x: ask ? x -- take question SEQ a 0 ? y SYNC bar -- wait for others ans ! 0 -- return answer d 0 ! 0 b 0 ? z ping ? x -- receive update SYNC bar -- wait for others c 0 ! 0 d 1 ! 0 : ping ? x -- receive update : PROC P 1 (CHAN INT a 1? , b 1? , c 1!, ask!, ans? , ping!, BARRIER bar) WHILE TRUE INT x, y, z: SEQ ask ! 0 -- ask question ans ? x -- wait for answer a 1 ? y b 1 ? z SYNC bar -- wait for the others c 1 ! 0 ping ! 0 -- update neighbour : 2/20/2021 Copyleft (GPL) P. H. Welch and J. B. Pedersen What’s first? 22

Informal Intuitive Behaviour: occam-π (executable) PROC P 0 (CHAN INT a 0? , b 0? , c 0!, ask? , ans!, BARRIER bar) PROC P 2 (CHAN INT d 0!, d 1!, ping? , WHILE TRUE BARRIER bar) INT x, y, z: WHILE TRUE SEQ INT x: ask ? x -- take question SEQ a 0 ? y SYNC bar -- wait for others ans ! 0 -- return answer d 0 ! 0 b 0 ? z ping ? x -- receive update SYNC bar -- wait for others c 0 ! 0 d 1 ! 0 : ping ? x -- receive update : PROC P 1 (CHAN INT a 1? , b 1? , c 1!, ask!, ans? , ping!, BARRIER bar) WHILE TRUE INT x, y, z: SEQ ask ! 0 -- ask question ans ? x -- wait for answer a 1 ? y b 1 ? z SYNC bar -- wait for the others c 1 ! 0 ping ! 0 -- update neighbour : 2/20/2021 What’s first? a 0 [a 0] Copyleft (GPL) P. H. Welch and J. B. Pedersen 23

Informal Intuitive Behaviour: occam-π (executable) PROC P 0 (CHAN INT a 0? , b 0? , c 0!, ask? , ans!, BARRIER bar) PROC P 2 (CHAN INT d 0!, d 1!, ping? , WHILE TRUE BARRIER bar) INT x, y, z: WHILE TRUE SEQ INT x: ask ? x -- take question SEQ a 0 ? y SYNC bar -- wait for others ans ! 0 -- return answer d 0 ! 0 b 0 ? z ping ? x -- receive update SYNC bar -- wait for others c 0 ! 0 d 1 ! 0 : ping ? x -- receive update : PROC P 1 (CHAN INT a 1? , b 1? , c 1!, ask!, ans? , ping!, BARRIER bar) WHILE TRUE INT x, y, z: SEQ ask ! 0 -- ask question ans ? x -- wait for answer a 1 ? y b 1 ? z SYNC bar -- wait for the others c 1 ! 0 ping ! 0 -- update neighbour : 2/20/2021 What’s second? [a 0] Copyleft (GPL) P. H. Welch and J. B. Pedersen 24

Informal Intuitive Behaviour: occam-π (executable) PROC P 0 (CHAN INT a 0? , b 0? , c 0!, ask? , ans!, BARRIER bar) PROC P 2 (CHAN INT d 0!, d 1!, ping? , WHILE TRUE BARRIER bar) INT x, y, z: WHILE TRUE SEQ INT x: ask ? x -- take question SEQ a 0 ? y SYNC bar -- wait for others ans ! 0 -- return answer d 0 ! 0 b 0 ? z ping ? x -- receive update SYNC bar -- wait for others c 0 ! 0 d 1 ! 0 : ping ? x -- receive update : PROC P 1 (CHAN INT a 1? , b 1? , c 1!, ask!, ans? , ping!, BARRIER bar) WHILE TRUE INT x, y, z: SEQ ask ! 0 -- ask question ans ? x -- wait for answer a 1 ? y b 1 ? z SYNC bar -- wait for the others c 1 ! 0 ping ! 0 -- update neighbour : 2/20/2021 What’s second? [a 0] Copyleft (GPL) P. H. Welch and J. B. Pedersen 25

Informal Intuitive Behaviour: occam-π (executable) PROC P 0 (CHAN INT a 0? , b 0? , c 0!, ask? , ans!, BARRIER bar) PROC P 2 (CHAN INT d 0!, d 1!, ping? , WHILE TRUE BARRIER bar) INT x, y, z: WHILE TRUE SEQ INT x: ask ? x -- take question SEQ a 0 ? y SYNC bar -- wait for others ans ! 0 -- return answer d 0 ! 0 b 0 ? z ping ? x -- receive update SYNC bar -- wait for others c 0 ! 0 d 1 ! 0 : ping ? x -- receive update : PROC P 1 (CHAN INT a 1? , b 1? , c 1!, ask!, ans? , ping!, BARRIER bar) WHILE TRUE INT x, y, z: SEQ ask ! 0 -- ask question ans ? x -- wait for answer a 1 ? y b 1 ? z SYNC bar -- wait for the others c 1 ! 0 ping ! 0 -- update neighbour : 2/20/2021 What’s second? b 0 or a 1 [a 0] Copyleft (GPL) P. H. Welch and J. B. Pedersen 26

Informal Intuitive Behaviour: occam-π (executable) PROC P 0 (CHAN INT a 0? , b 0? , c 0!, ask? , ans!, BARRIER bar) PROC P 2 (CHAN INT d 0!, d 1!, ping? , WHILE TRUE BARRIER bar) INT x, y, z: WHILE TRUE SEQ INT x: ask ? x -- take question SEQ a 0 ? y SYNC bar -- wait for others ans ! 0 -- return answer d 0 ! 0 b 0 ? z ping ? x -- receive update SYNC bar -- wait for others c 0 ! 0 d 1 ! 0 : ping ? x -- receive update : PROC P 1 (CHAN INT a 1? , b 1? , c 1!, ask!, ans? , ping!, BARRIER bar) WHILE TRUE INT x, y, z: SEQ ask ! 0 -- ask question ans ? x -- wait for answer a 1 ? y b 1 ? z SYNC bar -- wait for the others c 1 ! 0 ping ! 0 -- update neighbour : 2/20/2021 If b 0 second, then? [a 0, b 0] [a 0] Copyleft (GPL) P. H. Welch and J. B. Pedersen 27

Informal Intuitive Behaviour: occam-π (executable) PROC P 0 (CHAN INT a 0? , b 0? , c 0!, ask? , ans!, BARRIER bar) PROC P 2 (CHAN INT d 0!, d 1!, ping? , WHILE TRUE BARRIER bar) INT x, y, z: WHILE TRUE SEQ INT x: ask ? x -- take question SEQ a 0 ? y SYNC bar -- wait for others ans ! 0 -- return answer d 0 ! 0 b 0 ? z ping ? x -- receive update SYNC bar -- wait for others c 0 ! 0 d 1 ! 0 : ping ? x -- receive update : PROC P 1 (CHAN INT a 1? , b 1? , c 1!, ask!, ans? , ping!, BARRIER bar) WHILE TRUE INT x, y, z: SEQ ask ! 0 -- ask question ans ? x -- wait for answer a 1 ? y b 1 ? z SYNC bar -- wait for the others c 1 ! 0 ping ! 0 -- update neighbour : 2/20/2021 If b 0 second, then? a 1 [a 0, b 0] a 1] Copyleft (GPL) P. H. Welch and J. B. Pedersen 28

Informal Intuitive Behaviour: occam-π (executable) PROC P 0 (CHAN INT a 0? , b 0? , c 0!, ask? , ans!, BARRIER bar) PROC P 2 (CHAN INT d 0!, d 1!, ping? , WHILE TRUE BARRIER bar) INT x, y, z: WHILE TRUE SEQ INT x: ask ? x -- take question SEQ a 0 ? y SYNC bar -- wait for others ans ! 0 -- return answer d 0 ! 0 b 0 ? z ping ? x -- receive update SYNC bar -- wait for others c 0 ! 0 d 1 ! 0 : ping ? x -- receive update : PROC P 1 (CHAN INT a 1? , b 1? , c 1!, ask!, ans? , ping!, BARRIER bar) WHILE TRUE INT x, y, z: SEQ ask ! 0 -- ask question ans ? x -- wait for answer a 1 ? y b 1 ? z SYNC bar -- wait for the others c 1 ! 0 ping ! 0 -- update neighbour : 2/20/2021 If b 0 second, then? a 1 then b 1 [a 0, b 0, a 1] b 1] Copyleft (GPL) P. H. Welch and J. B. Pedersen 29

Informal Intuitive Behaviour: occam-π (executable) PROC P 0 (CHAN INT a 0? , b 0? , c 0!, ask? , ans!, BARRIER bar) PROC P 2 (CHAN INT d 0!, d 1!, ping? , WHILE TRUE BARRIER bar) INT x, y, z: WHILE TRUE SEQ INT x: ask ? x -- take question SEQ a 0 ? y SYNC bar -- wait for others ans ! 0 -- return answer d 0 ! 0 b 0 ? z ping ? x -- receive update SYNC bar -- wait for others c 0 ! 0 d 1 ! 0 : ping ? x -- receive update : PROC P 1 (CHAN INT a 1? , b 1? , c 1!, ask!, ans? , ping!, BARRIER bar) WHILE TRUE INT x, y, z: SEQ ask ! 0 -- ask question ans ? x -- wait for answer a 1 ? y b 1 ? z SYNC bar -- wait for the others c 1 ! 0 ping ! 0 -- update neighbour : 2/20/2021 If b 0 second, then? a 1 then b 1 [a 0, b 0, a 1, b 1] Copyleft (GPL) P. H. Welch and J. B. Pedersen 30

Informal Intuitive Behaviour: occam-π (executable) PROC P 0 (CHAN INT a 0? , b 0? , c 0!, ask? , ans!, BARRIER bar) PROC P 2 (CHAN INT d 0!, d 1!, ping? , WHILE TRUE BARRIER bar) INT x, y, z: WHILE TRUE SEQ INT x: ask ? x -- take question SEQ a 0 ? y SYNC bar -- wait for others ans ! 0 -- return answer d 0 ! 0 b 0 ? z ping ? x -- receive update SYNC bar -- wait for others c 0 ! 0 d 1 ! 0 : ping ? x -- receive update : PROC P 1 (CHAN INT a 1? , b 1? , c 1!, ask!, ans? , ping!, BARRIER bar) WHILE TRUE INT x, y, z: SEQ ask ! 0 -- ask question ans ? x -- wait for answer a 1 ? y b 1 ? z SYNC bar -- wait for the others c 1 ! 0 ping ! 0 -- update neighbour : 2/20/2021 backtracking … What’s second? b 0 or a 1 [a 0] Copyleft (GPL) P. H. Welch and J. B. Pedersen 31

Informal Intuitive Behaviour: occam-π (executable) PROC P 0 (CHAN INT a 0? , b 0? , c 0!, ask? , ans!, BARRIER bar) PROC P 2 (CHAN INT d 0!, d 1!, ping? , WHILE TRUE BARRIER bar) INT x, y, z: WHILE TRUE SEQ INT x: ask ? x -- take question SEQ a 0 ? y SYNC bar -- wait for others ans ! 0 -- return answer d 0 ! 0 b 0 ? z ping ? x -- receive update SYNC bar -- wait for others c 0 ! 0 d 1 ! 0 : ping ? x -- receive update : PROC P 1 (CHAN INT a 1? , b 1? , c 1!, ask!, ans? , ping!, BARRIER bar) WHILE TRUE INT x, y, z: SEQ ask ! 0 -- ask question ans ? x -- wait for answer a 1 ? y b 1 ? z SYNC bar -- wait for the others c 1 ! 0 ping ! 0 -- update neighbour : 2/20/2021 If a 1 second, then? [a 0, a 1] [a 0] Copyleft (GPL) P. H. Welch and J. B. Pedersen 32

Informal Intuitive Behaviour: occam-π (executable) PROC P 0 (CHAN INT a 0? , b 0? , c 0!, ask? , ans!, BARRIER bar) PROC P 2 (CHAN INT d 0!, d 1!, ping? , WHILE TRUE BARRIER bar) INT x, y, z: WHILE TRUE SEQ INT x: ask ? x -- take question SEQ a 0 ? y SYNC bar -- wait for others ans ! 0 -- return answer d 0 ! 0 b 0 ? z ping ? x -- receive update SYNC bar -- wait for others c 0 ! 0 d 1 ! 0 : ping ? x -- receive update : PROC P 1 (CHAN INT a 1? , b 1? , c 1!, ask!, ans? , ping!, BARRIER bar) WHILE TRUE INT x, y, z: SEQ ask ! 0 -- ask question ans ? x -- wait for answer a 1 ? y b 1 ? z SYNC bar -- wait for the others c 1 ! 0 ping ! 0 -- update neighbour : 2/20/2021 If a 1 second, then? b 0 and b 1 * [a 0, a 1] Copyleft (GPL) P. H. Welch and J. B. Pedersen (* any order) 33

Informal Intuitive Behaviour: occam-π (executable) PROC P 0 (CHAN INT a 0? , b 0? , c 0!, ask? , ans!, BARRIER bar) PROC P 2 (CHAN INT d 0!, d 1!, ping? , WHILE TRUE BARRIER bar) INT x, y, z: WHILE TRUE SEQ INT x: ask ? x -- take question SEQ a 0 ? y SYNC bar -- wait for others ans ! 0 -- return answer d 0 ! 0 b 0 ? z ping ? x -- receive update SYNC bar -- wait for others c 0 ! 0 d 1 ! 0 : ping ? x -- receive update : PROC P 1 (CHAN INT a 1? , b 1? , c 1!, ask!, ans? , ping!, BARRIER bar) WHILE TRUE INT x, y, z: SEQ ask ! 0 -- ask question ans ? x -- wait for answer a 1 ? y b 1 ? z SYNC bar -- wait for the others c 1 ! 0 ping ! 0 -- update neighbour : 2/20/2021 If a 1 second, then? b 0 and b 1 [a 0, a 1] a 1, b 0, b 1] [a 0, a 1, b 0] Copyleft (GPL) P. H. Welch and J. B. Pedersen 34

Informal Intuitive Behaviour: occam-π (executable) PROC P 0 (CHAN INT a 0? , b 0? , c 0!, ask? , ans!, BARRIER bar) PROC P 2 (CHAN INT d 0!, d 1!, ping? , WHILE TRUE BARRIER bar) INT x, y, z: WHILE TRUE SEQ INT x: ask ? x -- take question SEQ a 0 ? y SYNC bar -- wait for others ans ! 0 -- return answer d 0 ! 0 b 0 ? z ping ? x -- receive update SYNC bar -- wait for others c 0 ! 0 d 1 ! 0 : ping ? x -- receive update : PROC P 1 (CHAN INT a 1? , b 1? , c 1!, ask!, ans? , ping!, BARRIER bar) WHILE TRUE INT x, y, z: SEQ ask ! 0 -- ask question ans ? x -- wait for answer a 1 ? y b 1 ? z SYNC bar -- wait for the others c 1 ! 0 ping ! 0 -- update neighbour : 2/20/2021 If a 1 second, then? b 0 and b 1 [a 0, a 1, b 0, b 1] [a 0, a 1, b 0] Copyleft (GPL) P. H. Welch and J. B. Pedersen 35

Informal Intuitive Behaviour: occam-π (executable) PROC P 0 (CHAN INT a 0? , b 0? , c 0!, ask? , ans!, BARRIER bar) PROC P 2 (CHAN INT d 0!, d 1!, ping? , WHILE TRUE BARRIER bar) INT x, y, z: WHILE TRUE SEQ INT x: ask ? x -- take question SEQ a 0 ? y SYNC bar -- wait for others ans ! 0 -- return answer d 0 ! 0 b 0 ? z ping ? x -- receive update SYNC bar -- wait for others c 0 ! 0 d 1 ! 0 : ping ? x -- receive update : PROC P 1 (CHAN INT a 1? , b 1? , c 1!, ask!, ans? , ping!, BARRIER bar) WHILE TRUE INT x, y, z: SEQ ask ! 0 -- ask question ans ? x -- wait for answer a 1 ? y b 1 ? z SYNC bar -- wait for the others c 1 ! 0 ping ! 0 -- update neighbour : 2/20/2021 [a 0, Copyleft (GPL) P. H. Welch and J. B. Pedersen b 0, a 1, b 0, b 1, b 1] b 0] What next? 36

Informal Intuitive Behaviour: occam-π (executable) PROC P 0 (CHAN INT a 0? , b 0? , c 0!, ask? , ans!, BARRIER bar) PROC P 2 (CHAN INT d 0!, d 1!, ping? , WHILE TRUE BARRIER bar) INT x, y, z: WHILE TRUE SEQ INT x: ask ? x -- take question SEQ a 0 ? y SYNC bar -- wait for others ans ! 0 -- return answer d 0 ! 0 b 0 ? z ping ? x -- receive update SYNC bar -- wait for others c 0 ! 0 d 1 ! 0 : ping ? x -- receive update : PROC P 1 (CHAN INT a 1? , b 1? , c 1!, ask!, ans? , ping!, BARRIER bar) WHILE TRUE INT x, y, z: SEQ ask ! 0 -- ask question ans ? x -- wait for answer a 1 ? y b 1 ? z SYNC bar -- wait for the others c 1 ! 0 ping ! 0 -- update neighbour : 2/20/2021 [a 0, Copyleft (GPL) P. H. Welch and J. B. Pedersen b 0, a 1, b 0, b 1, b 1] b 0] What next? c 0 c 1 (* any order) d 0 * 37

Informal Intuitive Behaviour: occam-π (executable) PROC P 0 (CHAN INT a 0? , b 0? , c 0!, ask? , ans!, BARRIER bar) PROC P 2 (CHAN INT d 0!, d 1!, ping? , WHILE TRUE BARRIER bar) INT x, y, z: WHILE TRUE SEQ INT x: ask ? x -- take question SEQ a 0 ? y SYNC bar -- wait for others ans ! 0 -- return answer d 0 ! 0 b 0 ? z ping ? x -- receive update SYNC bar -- wait for others c 0 ! 0 d 1 ! 0 : ping ? x -- receive update : PROC P 1 (CHAN INT a 1? , b 1? , c 1!, ask!, ans? , ping!, BARRIER bar) WHILE TRUE INT x, y, z: SEQ ask ! 0 -- ask question ans ? x -- wait for answer a 1 ? y b 1 ? z SYNC bar -- wait for the others c 1 ! 0 ping ! 0 -- update neighbour : 2/20/2021 That’s 18 possible orderings of the first 7 signals. What happens when the sub-processes start looping? Copyleft (GPL) P. H. Welch and J. B. Pedersen 38

Informal Intuitive Behaviour: occam-π (executable) PROC P 0 (CHAN INT a 0? , b 0? , c 0!, ask? , ans!, BARRIER bar) PROC P 2 (CHAN INT d 0!, d 1!, ping? , WHILE TRUE BARRIER bar) INT x, y, z: WHILE TRUE SEQ INT x: ask ? x -- take question SEQ a 0 ? y SYNC bar -- wait for others ans ! 0 -- return answer d 0 ! 0 b 0 ? z ping ? x -- receive update SYNC bar -- wait for others c 0 ! 0 d 1 ! 0 : ping ? x -- receive update : PROC P 1 (CHAN INT a 1? , b 1? , c 1!, ask!, ans? , ping!, BARRIER bar) WHILE TRUE INT x, y, z: SEQ ask ! 0 -- ask question ans ? x -- wait for answer a 1 ? y b 1 ? z SYNC bar -- wait for the others c 1 ! 0 ping ! 0 -- update neighbour : 2/20/2021 Could P 0 signal again on a 0 before P 2 gave its first d 0? Are there some more possible first-7 signal sequences? Copyleft (GPL) P. H. Welch and J. B. Pedersen 39

Formal Behaviour: CSP-M (verifyable) a 0 b 0 c 0 a 1 b 1 ask P 0 P 1 c 1 d 0 d 1 ping P 2 ans Device bar We can formally verify the previous intuition (which was only about the opening behaviour of the system) and answer the open questions (and more) about its continuous behaviour with a CSP representation. We use CSP-M, the machine readable form used by the FDR 2 model checker. CSP-M is a declarative (functional) language – loops map to tail recursions. Students who enjoy programming have no problem learning new syntax (it’s particularly easy when the semantics remain unchanged) – but they need to be told why! 2/20/2021 Copyleft (GPL) P. H. Welch and J. B. Pedersen 40

Formal Behaviour: CSP-M (verifyable) a 0 b 0 c 0 a 1 b 1 ask P 0 P 1 c 1 d 0 d 1 ping P 2 ans Device bar CSP-M lets us abstract the channel communications further by omitting the data sent (always zero in our example) and the direction of communication (irrelevant here). CSP processes synchronise only on events, which capture the notions of point-to-point channels and multiway barriers. CSP-M calls them all channels. In the following CSP-M, we further simplify things by omitting process parameters and accessing all channels from global declaration. [We could have done this with the occam-π …] 2/20/2021 Copyleft (GPL) P. H. Welch and J. B. Pedersen 41

Formal Behaviour: CSP-M (verifyable) a 0 b 0 c 0 a 1 b 1 ask P 0 P 1 c 1 d 0 d 1 ping P 2 ans Device channel a 0, P 0 = ask -> 2/20/2021 bar , ns! a , sk? a b 0, c 0, a 1, b 1, c 1, d 0, d 1, ask, , cans 0!, , ping, b 0? , ? 0 T a r) N I a 0 -> ans -> b 0 -> bar a -> P 0 bc 0 AN -> H R C E ( I P 0 ion ARR t B C s PRO que RUE , z: e T k er y ta LE nsw -WHI NT x, a I urn t ers x e Q h r E t ? S o -or ask ? y f 0 ait a 0 w ! -ans ? z b 0 C bar SYN ! 0 c 0 : Copyleft (GPL) P. H. Welch and J. B. Pedersen bar 42

Formal Behaviour: CSP-M (verifyable) a 0 b 0 c 0 a 1 ask channel a 0, P 0 = ask: -> P 1 = ask -> 2/20/2021 b 1 c 1 d 0 d 1 ping PRP 0 P 1 P 2 OC P 1 ans (C WH HA IL N B E AR IN I T Device NT RU RIE T a R 1? bar SE x, E b Q ar , b y, ) 1? as z: , k c 1 an ! !, s 0 as a 1 ? k x ? , a 1, b 1 b 0, b 1 c 0 , ans, ping, -- , c 1, d 0, d 1, !, ask y an ? a s? SY -sk z , N wa qu pi c 1 C b it es ng ar ! t !, pi -> a 0 ans -> b 0 -> bar -> c 0 -> P 0 f i 0 o o ng r n -an ! sw 0 wa er it ans -> a 1 -- -> b 1 for-> bar -> c 1 -> ping -> P 1 up th da e te ot ne he ig rs hb ou r Copyleft (GPL) P. H. Welch and J. B. Pedersen bar 43

Formal Behaviour: CSP-M (verifyable) a 0 b 0 c 0 a 1 b 1 ask P 0 P 1 c 1 d 0 d 1 ping P 2 ans ? , ing p , d 1! , Device d 0! bar NT ) I r N ba CHA IER ( rs R P 2 the BAR C o O PR for RUE T t i te , d 1, ask, ans, ping, wab 1 ILEb 0 dad 0 : c 0, a 1 channel a 0 , , , c 1 , p x WH, u rs ve INT the i o e r a rec for SEQ NC b t Y e S ai wb 0 dat -> c 0 -> P 0 ! 0 ans P 0 = ask -> a 0 -> -> -> bar p x u 0 d g ? r ive e c a pin re C b -SYN 0 ! a 1 P 1 = ask -> ansd 1 -> -> b 1 -> bar -> c 1 -> ping -> P 1 ? x g pin bar P 2 = bar -> : d 0 -> ping -> bar -> d 1 -> ping -> P 2 2/20/2021 Copyleft (GPL) P. H. Welch and J. B. Pedersen 44

Formal Behaviour: CSP-M (verifyable) a 0 b 0 c 0 a 1 b 1 ask P 0 P 1 c 1 d 0 d 1 ping P 2 ans Device bar channel a 0, b 0, c 0, a 1, b 1, c 1, d 0, d 1, ask, ans, ping, bar P 0 = ask -> a 0 -> ans -> b 0 -> bar -> c 0 -> P 0 P 1 = ask -> ans -> a 1 -> bar -> c 1 -> ping -> P 1 P 2 = bar -> d 0 -> ping -> bar -> d 1 -> ping -> P 2 P 0 P 1 = (P 0 [| {ask, ans, bar} |] P 1) {ask, ans} Device = (P 0 P 1 [| {ping, bar} |] P 2) {ping, bar} 2/20/2021 Copyleft (GPL) P. H. Welch and J. B. Pedersen 45

Formal Behaviour: CSP-M (verifyable) Loading the system below into FDR 2, we discover straight away that Device is free from deadlock and livelock – just click the buttons! channel a 0, b 0, c 0, a 1, b 1, c 1, d 0, d 1, ask, ans, ping, bar P 0 = ask -> a 0 -> ans -> b 0 -> bar -> c 0 -> P 0 P 1 = ask -> ans -> a 1 -> bar -> c 1 -> ping -> P 1 P 2 = bar -> d 0 -> ping -> bar -> d 1 -> ping -> P 2 P 0 P 1 = (P 0 [| {ask, ans, bar} |] P 1) {ask, ans} Device = (P 0 P 1 [| {ping, bar} |] P 2) {ping, bar} 2/20/2021 Copyleft (GPL) P. H. Welch and J. B. Pedersen 46

Formal Behaviour: CSP-M (verifyable) Intuition Informal understanding To check whether particular event sequences (traces) may initially be performed by Device … e. g. [a 0, b 0, a 1, b 1] [a 0, a 1, b 0, b 1] [a 0, a 1, b 0] What next? Define processes that have no choice in the matter … e. g. c 0 c 1 d 0 * (* any order) T 0 = a 0 -> b 0 -> a 1 -> b 1 -> d 0 -> c 1 -> STOP T 1 = a 0 -> b 0 -> a 1 -> d 0 -> b 1 -> c 0 -> c 1 -> STOP And ask: does each trace refine Device? Process P trace refines Q if all traces of P are traces of Q. 2/20/2021 Q [T= P Copyleft (GPL) P. H. Welch and J. B. Pedersen 47

Formal Behaviour: CSP-M (verifyable) Intuition Informal understanding To check whether particular event sequences (traces) may initially be performed by Device … e. g. [a 0, b 0, a 1, b 1] [a 0, a 1, b 0, b 1] [a 0, a 1, b 0] What next? Define processes that have no choice in the matter … e. g. c 0 c 1 d 0 * (* any order) T 0 = a 0 -> b 0 -> a 1 -> b 1 -> d 0 -> c 1 -> STOP T 1 = a 0 -> b 0 -> a 1 -> d 0 -> b 1 -> c 0 -> c 1 -> STOP FDR 2 reports that T 0 trace refines Device … but T 1 does not – which confirms our intuition. Device [T= T 0 2/20/2021 ✔ Device [T= T 1 Copyleft (GPL) P. H. Welch and J. B. Pedersen ✗ 48

Formal Behaviour: CSP-M (verifyable) Intuition Informal understanding To check whether particular event sequences (traces) may initially be performed by Device … e. g. [a 0, b 0, a 1, b 1] [a 0, a 1, b 0, b 1] [a 0, a 1, b 0] What next? Define processes that have no choice in the matter … e. g. c 0 c 1 d 0 * (* any order) T 0 = a 0 -> b 0 -> a 1 -> b 1 -> d 0 -> c 1 -> STOP T 1 = a 0 -> b 0 -> a 1 -> d 0 -> b 1 -> c 0 -> c 1 -> STOP Clearly, [a 0, b 0, a 1, b 1, d 0, c 1] is a trace of T 0. Therefore, it is also a trace of Device [T= T 0 2/20/2021 ✔ Copyleft (GPL) P. H. Welch and J. B. Pedersen 49

Formal Behaviour: CSP-M (verifyable) Intuition Informal understanding To check whether particular event sequences (traces) may initially be performed by Device … e. g. [a 0, b 0, a 1, b 1] [a 0, a 1, b 0, b 1] [a 0, a 1, b 0] What next? Define processes that have no choice in the matter … e. g. c 0 c 1 d 0 * (* any order) T 0 = a 0 -> b 0 -> a 1 -> b 1 -> d 0 -> c 1 -> STOP T 1 = a 0 -> b 0 -> a 1 -> d 0 -> b 1 -> c 0 -> c 1 -> STOP At least one trace of T 1 is not a trace of Device. Comparing T 0 and T 1, T 1 the fault lies in the mis-ordering of d 0 and b 1. Device [T= T 1 2/20/2021 Copyleft (GPL) P. H. Welch and J. B. Pedersen ✗ 50

Formal Behaviour: CSP-M (verifyable) a 0 b 0 c 0 a 1 b 1 ask P 0 P 1 c 1 d 0 ping Safety d 1 P 2 ans Device bar Let’s ask a more difficult question about the continuous running of the system. Suppose the robot would do something very bad if its controller Device were ever to signal twice on a 0 without a signal on d 0 or d 1 in between. Might this ever happen? Simple: write a process checking the signals to/from Device, looking for the bad scenario and deadlocks if spotted. This is just programming … 2/20/2021 Copyleft (GPL) P. H. Welch and J. B. Pedersen 51

Behaviour: CSP-M (verifyable) Formal a 0 b 0 c 0 a 1 b 1 ask P 0 P 1 c 1 d 0 ping Safety d 1 P 2 ans Device Check (n) if n >= a 0 -> a 1 -> c 0 -> bar = 2 then STOP Check (n+1) Check (n) else [] d 0 -> Check (0) [] d 1 -> Check (0) [] [] b 0 -> Check (n) [] b 1 -> Check (n) [] [] c 1 -> Check (n) Simple: write a process checking the signals to/from Device, looking for the bad scenario and deadlocks if spotted. This is just programming … 2/20/2021 Copyleft (GPL) P. H. Welch and J. B. Pedersen 52

Behaviour: CSP-M (verifyable) Formal a 0 b 0 c 0 a 1 b 1 ask P 0 P 1 c 1 d 0 ping Safety d 1 P 2 ans Device Check (n) if n >= a 0 -> a 1 -> c 0 -> bar = 2 then STOP Check (n+1) Check (n) else [] d 0 -> Check (0) [] d 1 -> Check (0) [] [] b 0 -> Check (n) [] b 1 -> Check (n) [] [] c 1 -> Check (n) The operator “[]” means wait for one or more of the operand processes to become able to run … choose one of them and run. 2/20/2021 Copyleft (GPL) P. H. Welch and J. B. Pedersen 53

Behaviour: CSP-M (verifyable) Formal a 0 b 0 c 0 a 1 b 1 ask P 0 P 1 c 1 d 0 ping Safety d 1 P 2 ans Device Check (n) if n >= a 0 -> a 1 -> c 0 -> bar = 2 then STOP Check (n+1) Check (n) else [] d 0 -> Check (0) [] d 1 -> Check (0) [] [] b 0 -> Check (n) [] b 1 -> Check (n) [] [] c 1 -> Check (n) The parameter to Check records how many a 0 signals have been received since the last d 0 or d 1, stopping if this reaches 2. 2/20/2021 Copyleft (GPL) P. H. Welch and J. B. Pedersen 54

Formal Behaviour: CSP-M (verifyable) a 0 b 0 c 0 a 1 b 1 ask P 0 P 1 c 1 Safety d 0 d 1 ping P 2 ans Device Check (n) if n >= a 0 -> a 1 -> c 0 -> bar = 2 then STOP Check (n+1) Check (n) else [] d 0 -> Check (0) [] d 1 -> Check (0) [] [] b 0 -> Check (n) [] b 1 -> Check (n) [] [] c 1 -> Check (n) Check. Device = Device [| {a 0, b 0, c 0, a 1, b 1, c 1, d 0, d 1} |] Check (0) If Check (0) stops, Check. Device will deadlock. Q. E. D. FDR 2 reports Check. Device is deadlock free. Therefore, Check (0) never stops (& the bad thing can’t happen). 2/20/2021 Copyleft (GPL) P. H. Welch and J. B. Pedersen 55

Formal Behaviour: CSP-M (verifyable) a 0 b 0 c 0 a 1 b 1 ask P 0 P 1 c 1 Safety d 0 d 1 ping P 2 ans Device bar Note: protocol checking monitors, such as Check, are sometimes used live to ensure adherence at run-time (e. g. in device drivers). We are using Check purely for static analysis – it has no role at run-time and, therefore, no impact on performance. If Check (0) stops, Check. Device will deadlock. Q. E. D. FDR 2 reports Check. Device is deadlock free. Therefore, Check (0) never stops (& the bad thing can’t happen). 2/20/2021 Copyleft (GPL) P. H. Welch and J. B. Pedersen 56

Formal Behaviour: CSP-M (verifyable) a 0 b 0 c 0 a 1 b 1 ask P 0 P 1 c 1 Liveness d 0 d 1 ping P 2 ans Device bar So far, our checks have concerned safety – namely that our system will not do harm (incorrect things). This is not enough! After all, the STOP process does not do incorrect things – it does nothing. STOP trace refines every process. Trace refinement is not enough. A CSP failure is a state that a system reaches (represented by its trace to that point) where it may refuse to synchronise with its environment on some given set of events. Process P failure refines Q if (all traces of P are traces of Q) and (all failures of P are failures of Q). 2/20/2021 Copyleft (GPL) P. H. Welch and J. B. Pedersen 57

Formal Behaviour: CSP-M (verifyable) a 0 b 0 c 0 a 1 b 1 ask P 0 P 1 c 1 Liveness d 0 d 1 ping P 2 ans Device bar A CSP failure is a state that a system reaches (represented by its trace to that point) where it may refuse to synchronise with its environment on some given set of events. Process P failure refines Q if (all its traces are traces of Q) and (all its failures are failures of Q). This is a powerful statement! P can only do traces of Q (so its safe). More: the failures of P are allowed by Q. If P and Q execute the same trace to a state where their environment offers a set of events that Q will not refuse, then P also will not refuse. 2/20/2021 Copyleft (GPL) P. H. Welch and J. B. Pedersen 58

Formal Behaviour: CSP-M (verifyable) a 0 b 0 c 0 a 1 b 1 ask P 0 P 1 c 1 Liveness d 0 d 1 ping P 2 ans Device bar A CSP failure is a state that a system reaches (represented by its trace to that point) where it may refuse to synchronise with its environment on some given set of events. Process P failure refines Q if (all its traces are traces of Q) and (all its failures are failures of Q). Whenever Q stays alive (engaging with its environment), so does P (and in the same way). If Q is a specification directly written to express the required patterns of synchronisation, P will fulfil them. 2/20/2021 Copyleft (GPL) P. H. Welch and J. B. Pedersen 59

Formal Behaviour: CSP-M (verifyable) a 0 b 0 c 0 a 1 b 1 ask P 0 P 1 c 1 Liveness d 0 d 1 ping P 2 ans Device bar Recall our informal understanding of (at least some of) the opening traces of Device (slides 20 -37) … We can formalise the expression of those traces a bit better … Informal understanding [a 0, b 0, a 1, b 0, b 1, b 1] b 0] What next? c 0 c 1 d 0 * (* any order) 2/20/2021 Copyleft (GPL) P. H. Welch and J. B. Pedersen 60

Formal Behaviour: CSP-M (verifyable) a 0 b 0 c 0 a 1 b 1 ask P 0 P 1 c 1 Liveness d 0 d 1 ping P 2 ans Device bar Recall our informal understanding of (at least some of) the opening traces of Device (slides 20 -37) … We can formalise the expression of those traces a bit better … Informal understanding [a 0, b 0, a 1, b 0, b 1, b 1] b 0] [c 0] ||| [c 1] ||| [d 0] interleave 2/20/2021 Copyleft (GPL) P. H. Welch and J. B. Pedersen 61

Formal Behaviour: CSP-M (verifyable) a 0 b 0 c 0 a 1 b 1 ask P 0 P 1 c 1 Liveness d 0 d 1 ping P 2 ans Device bar Recall our informal understanding of (at least some of) the opening traces of Device (slides 20 -37) … We can formalise the expression of those traces a bit better … Informal understanding [a 0] [b 0] ||| [a 1, b 1] [c 0] ||| [c 1] ||| [d 0] interleave 2/20/2021 Copyleft (GPL) P. H. Welch and J. B. Pedersen 62

Formal Behaviour: CSP-M (verifyable) a 0 b 0 c 0 a 1 b 1 ask P 0 P 1 c 1 Liveness d 0 d 1 ping P 2 ans Device bar Recall our informal understanding of (at least some of) the opening traces of Device (slides 20 -37) … We can formalise the expression of those traces a bit better … Informal understanding [a 0] [b 0] ||| [a 1, b 1] [c 0] ||| [c 1] ||| [d 0] [a 0]; ([b 0] ||| [a 1, b 1]); ([c 0] ||| [c 1] ||| [d 0]) 2/20/2021 Copyleft (GPL) P. H. Welch and J. B. Pedersen 63

Formal Behaviour: CSP-M (verifyable) a 0 b 0 c 0 a 1 b 1 ask P 0 P 1 c 1 Liveness d 0 d 1 ping P 2 ans Device bar And, still using our intuitive understanding, guess the next cycle of events … We can formalise the expression of those traces a bit better … [a 0]; ([b 0] ||| [a 1, b 1]); ([c 0] ||| [c 1] ||| [d 0]); [a 0]; ([b 0] ||| [a 1, b 1]); ([c 0] ||| [c 1] ||| [d 1]) 2/20/2021 Copyleft (GPL) P. H. Welch and J. B. Pedersen 64

Formal Behaviour: CSP-M (verifyable) a 0 b 0 c 0 a 1 b 1 ask P 0 P 1 c 1 Liveness d 0 d 1 ping P 2 ans Device bar And, still using our intuitive understanding, guess the next cycle of events … We can formalise the expression of those traces a bit better … ( 2/20/2021 And the rest … ) [a 0]; ([b 0] ||| [a 1, b 1]); ([c 0] ||| [c 1] ||| [d 0]); [a 0]; ([b 0] ||| [a 1, b 1]); ([c 0] ||| [c 1] ||| [d 1]) Copyleft (GPL) P. H. Welch and J. B. Pedersen * 65

Formal Behaviour: CSP-M (verifyable) a 0 b 0 c 0 a 1 b 1 c 1 ask P 0 d 1 ping P 1 Liveness P 2 ans Device bar Device. Spec = a 0 -> (b 0 -> SKIP ||| (c 0 -> SKIP ||| c 1 -> a 1 -> b 1 SKIP ||| -> d 0 -> d 1 SKIP); -> SKIP); Device. Spec From such trace expressions, we can directly write down a CSP process that offers all of them to its environment … ( 2/20/2021 This generation can be automated. ) [a 0]; ([b 0] ||| [a 1, b 1]); ([c 0] ||| [c 1] ||| [d 0]); [a 0]; ([b 0] ||| [a 1, b 1]); ([c 0] ||| [c 1] ||| [d 1]) Copyleft (GPL) P. H. Welch and J. B. Pedersen * 66

Formal Behaviour: CSP-M (verifyable) a 0 b 0 c 0 a 1 b 1 ask P 0 P 1 c 1 Liveness d 0 d 1 ping P 2 ans Device bar Device. Spec = a 0 -> (b 0 -> SKIP ||| (c 0 -> SKIP ||| c 1 -> a 1 -> b 1 SKIP ||| -> d 0 -> d 1 SKIP); -> SKIP); Device. Spec is an explicit specification of all signal patterns we expect (or need) Device to be able to perform. FDR 2 reports Device failure refines Check. Device. In fact, the reverse is also true – they have exactly the same traces and failures. 2/20/2021 Copyleft (GPL) P. H. Welch and J. B. Pedersen 67

Formal Behaviour: CSP-M (verifyable) a 0 b 0 c 0 a 1 b 1 ask P 0 P 1 c 1 Liveness d 0 d 1 ping P 2 ans Device bar Device. Spec = a 0 -> (b 0 -> SKIP ||| (c 0 -> SKIP ||| c 1 -> a 1 -> b 1 SKIP ||| -> d 0 -> d 1 SKIP); -> SKIP); Device. Spec Device was not implemented as Device. Spec because of the three independent functions (weapons systems, vision processing and motion stability) it had to perform. Process-oriented design led to its three communicating sub-systems. 2/20/2021 Copyleft (GPL) P. H. Welch and J. B. Pedersen 68

Formal Behaviour: CSP-M (verifyable) a 0 b 0 c 0 a 1 b 1 ask P 0 P 1 c 1 Liveness d 0 d 1 ping P 2 ans Device bar Device. Spec = a 0 -> (b 0 -> SKIP ||| (c 0 -> SKIP ||| c 1 -> a 1 -> b 1 SKIP ||| -> d 0 -> d 1 SKIP); -> SKIP); Device. Spec Whilst our intuition indicated that the first two lines of Device. Spec reflected the initial behaviour of Device, it was unclear whether the pattern repeated cleanly as its sub-components started looping. 2/20/2021 Copyleft (GPL) P. H. Welch and J. B. Pedersen 69

Formal Behaviour: CSP-M (verifyable) a 0 b 0 c 0 a 1 b 1 ask P 0 P 1 c 1 Liveness d 0 d 1 ping P 2 ans Device bar Device. Spec = a 0 -> (b 0 -> SKIP ||| (c 0 -> SKIP ||| c 1 -> a 1 -> b 1 SKIP ||| -> d 0 -> d 1 SKIP); -> SKIP); Device. Spec One way to ensure this is to add another barrier (bar) at the end of each loop of P 0 and P 1 and half-loop of P 2. The failures equivalence of Device and Device. Spec shows that the pattern does indeed repeat cleanly and, so, this overhead is not necessary. 2/20/2021 Copyleft (GPL) P. H. Welch and J. B. Pedersen 70

Formal Behaviour: CSP-M (verifyable) a 0 b 0 c 0 a 1 b 1 ask P 0 P 1 c 1 Liveness d 0 d 1 ping P 2 ans Device bar Device. Spec = a 0 -> (b 0 -> SKIP ||| (c 0 -> SKIP ||| c 1 -> a 1 -> b 1 SKIP ||| -> d 0 -> d 1 SKIP); -> SKIP); Device. Spec Rather than being deduced after implementation, Device. Spec may be part of the specification for the behaviour of Device. We certainly need assurance of the behaviour of Device to use it securely with other components. All its patterns of synchronisation (for safety and liveness questions) can be trivially deduced from Device. Spec. 2/20/2021 Copyleft (GPL) P. H. Welch and J. B. Pedersen 71

Reflection Class experience The case study presented was developed from one first worked through in a single lesson of a graduate class in concurrency at UNLV in the spring of 2010. They had previously studied a range of concurrency approaches, including process-oriented material from the Kent “Concurrency Design and Practice” course (presented at last year’s workshop). They were comfortable with using occam-π in non-trivial projects (thousands of interacting processes), so the example system here would be considered fairly simple. Nevertheless, it was appreciated that relying just on intuitive understanding is unsafe – especially if the application were safety critical. 2/20/2021 Copyleft (GPL) P. H. Welch and J. B. Pedersen 72

Reflection Class experience During the exercise, students were given an overview (through examples) of CSP-M syntax, with semantics defined by relating back to occam-π syntax and semantics. The functional nature of CSP-M, compared with the imperative nature of occam-π, was no particular problem. Working with FDR 2 through its GUI was not very sexy (by modern GUI standards) – but easy enough. Checking their own (initial) test sequences for Device signals was very simple. Correct confirms/rejects were obtained. Writing safety-checking processes (like Device) for long term dangers was harder – but they warmed to this with practice. 2/20/2021 Copyleft (GPL) P. H. Welch and J. B. Pedersen 73

Reflection Class experience What-ifs on the behaviour of the system could be explored answered without running any code … e. g. If the (internal) ping communications were removed, does Check still hold? No Do the a 0 and a 1 signals strictly alternate? Yes Do the b 0 and b 1 signals strictly alternate? No If we added an extra bar sync at the end of each cycle in P 0 and P 1 and half-cycle in P 2, would it make any difference? No If the elevator cabin is not at a floor, might the floor doors to the elevator shaft still open? 2/20/2021 Copyleft (GPL) P. H. Welch and J. B. Pedersen Another exercise … 74

Reflection occam-π / CSP-M occam-π teams well with CSP-M to provide efficient executables and rich formal analysis. Of course, it would be better if only one syntactic representation were needed. We are working on extending occam-π to include verification assertions (about deadlock, livelock, determinism and refinement). Its compiler will generate suitably abstracted CSP-M and interact with the FDR 2 model checker, feeding back results in terms of the source occam-π program. Together with the ancient formal Laws of occam Programming *, this moves occam-π towards a process algebra in its own right. * http: //portal. acm. org/citation. cfm? id=53255 [A. W. Roscoe and C. A. R. Hoare, 1988] 2/20/2021 Copyleft (GPL) P. H. Welch and J. B. Pedersen 75

Reflection Observation Formal verification of the behaviour of concurrent processes has been achieved – by students – even though they engaged in only simple reasoning themselves. The complexity of synchronisation and communication analysed went far beyond the embarrassingly parallel. Aside: model checking found an error overlooked in developing the case study on paper (the need for ping) … which shows the necessity formal checks (especially when those responsible think they won’t make mistakes!). Further reading: Santa Claus: Formal Analysis of a Process Oriented Solution *. * 2/20/2021 http: /doi. acm. org/10. 1145/1734206. 1734211 TOPLAS, [April, 2010] Copyleft (GPL) P. H. Welch and J. B. Pedersen 76

Final Observation Can we teach students (those who love to program, anyway) concurrency so that: they quickly develop a correct and intuitive understanding of the primitive mechanisms (e. g. processes, communication, synchronisation, networks) and higher level patterns (e. g. client-server, phased barrier, I/O-PAR) … ? they can use those primitives and patterns with the same fluency as they use serial computing primitives, without tripping over dark hazards … ? they can develop their own patterns when the standard ones don’t apply … ? they can use formal methods to verify good behaviour (e. g. freedom from deadlock and livelock, safety, liveness), without training in the underlying mathematics (process algebra, denotational semantics) … ? they can do this as normal everyday practice, without any sense of fear … ? 2/20/2021 Copyleft (GPL) P. H. Welch and J. B. Pedersen 77

Final Observation Any questions? Can we teach students (those who love to program, anyway) concurrency so that: they quickly develop a correct and intuitive understanding of the primitive mechanisms (e. g. processes, communication, synchronisation, networks) and higher level patterns (e. g. client-server, phased barrier, I/O-PAR) … ? ! n a c they can use those primitives and patterns with the same fluency as they use serial computing primitives, without tripping over dark hazards … ? e w , s e Y they can develop their own patterns when the standard ones don’t apply … ? they can use formal methods to verify good behaviour (e. g. freedom from deadlock and livelock, safety, liveness), without training in the underlying mathematics (process algebra, denotational semantics) … ? they can do this as normal everyday practice, without any sense of fear … ? 2/20/2021 Copyleft (GPL) P. H. Welch and J. B. Pedersen 78