Concurrency and occam an overview Peter Welch phwsei

Concurrency and occam- : an overview Peter Welch (phw@sei. cmu. edu, phw@kent. ac. uk) Concurrency and occam-π 12/3/2020 Copyright P. H. Welch 1

Nature is not serial. . . Components must compose … CSP, processes, patterns … It was twenty years ago today … Threads considered harmful … Modelling complex systems … Blood clotting, robots, parrots … 12/3/2020 Copyright P. H. Welch 2

Natural systems are not controlled by / organised around a single thread of control: sue. eat. Breakfast (); joe. wash. Up (); sue. drive. To. Work (); joe. drink (beer); US. government. sue (bill); sun. zap (office); 12/3/2020 Copyright P. H. Welch ? ? ? 3

Nature is very large numbers of concurrent agents, interacting with each other in regular and chaotic patterns, at all levels of scale: … nanite … human … astronomic. . . 12/3/2020 Copyright P. H. Welch 4

Natural networks are dynamic: growing, decaying and mutating internal topology (in response to environmental pressure and self-motivation): … nanite … human … astronomic. . . 12/3/2020 Copyright P. H. Welch 5

Natural networks are dynamic: growing, decaying and mutating internal topology (in response to environmental pressure and self-motivation): … nanite … human … astronomic. . . 12/3/2020 Copyright P. H. Welch 6

Natural networks are massively concurrent. Whilst continuously evolving, they are robust, efficient and long-lived. We should take the hint! n Thesis u Look on concurrency as a core design mechanism – not as something difficult, used only to boost performance. n Where? u Hardware design and modelling. u Biological and physical system modelling. u Static and field-programmable embedded systems. u Dynamic supercomputing. u e. Commerce, dynamic distributed systems. u Operating systems, games, robotics, … 12/3/2020 Copyright P. H. Welch 7

Natural networks are massively concurrent. Whilst continuously evolving, they are robust, efficient and long-lived. We should take the hint! n Thesis u Look on concurrency as a core design mechanism – not as something difficult, used only to boost performance. n Where? u Hardware design and modelling. u Biological and physical system e r e u Static and field-programmable embedded systems. h w ry e u Dynamic supercomputing. Ev u e. Commerce, dynamic distributed systems. u Operating systems, games, robotics, … 12/3/2020 Copyright P. H. Welch 8

Concurrency and Computer Systems Computer systems – to be of use in this world – need to model that part of the world for which it is to be used. If that modeling can reflect the natural concurrency in the system … it should be simpler. Yet concurrency is thought to be an advanced topic, harder than serial computing (which therefore needs to be mastered first). 12/3/2020 Copyright P. H. Welch 9

This tradition makes no sense … … which has (radical) implications on how we should educate people for computer science … … and on how we apply what we have learnt … 12/3/2020 Copyright P. H. Welch 10

What we want from Parallelism n n n 12/3/2020 A powerful tool for simplifying the description of systems. Performance that spins out from the above, but is not the primary focus. A model of concurrency that is mathematically clean, yields no engineering surprises and scales well with system complexity. Copyright P. H. Welch 11

Multi-Pong 12/3/2020 Copyright P. H. Welch 12

left right scorer Multi. Pong keycontrol . . . collision detect canvas control new game 12/3/2020 flasher mouse freeze Copyright P. H. Welch 13

Good News! The good news is that we can worry about each process on its own. A process interacts with its environment through its channels. It does not interact directly with other processes. Some processes have serial implementations - these are just like traditional serial programs. Some processes have parallel implementations networks of sub-processes (think hardware). Our skills for serial logic sit happily alongside our new skills for concurrency - there is no conflict. This will scale! 12/3/2020 Copyright P. H. Welch 14

Nature is not serial. . . Components must compose … CSP, processes, patterns … It was twenty years ago today … Threads considered harmful … Modelling complex systems … Blood clotting, robots, parrots … 12/3/2020 Copyright P. H. Welch 15

Components? Components must be composeable … … and they must compose simply! simply 12/3/2020 Copyright P. H. Welch 16

Components? Mind you, just because components compose … … doesn’t always mean that it makes sense … 12/3/2020 Copyright P. H. Welch 17

Components? * … to compose them … *Image courtesy of Philips TASS <http: //www. tass. philips. com/> 12/3/2020 Copyright P. H. Welch 18

Components? n If we understand A and B separately, we must be able to deduce simply their combined behaviour. plug together no surprises n Semantics [A + B] = Semantics [A] + Semantics [B] n A and B must be composeable … 12/3/2020 Copyright P. H. Welch 19

Composition? Complex systems are composed from simpler components … … which are composed from simpler components … … … which are composed from simple components. 12/3/2020 Copyright P. H. Welch 20

Composition? n n n n Composition rules must be simple and yield no surprises. Whatever it is they encapsulate, components must have interfaces that are clean, complete and explicit. Protocols defining patterns of use of its interface must be specified and honored by the component implementation. As components are plugged together (parallel composition), connected interfaces (and the protocols for using them) must match. Depending on the protocols, there may be some higher-level rules to be checked during composition (e. g. the absence of cycles). Hardware systems are forced (by physics/geometry) to be built like this. Software systems have no such constraints. We think we can do better than nature … and get into trouble. 12/3/2020 Copyright P. H. Welch 21

Nature is not serial. . . Components must compose … CSP, processes, patterns … It was twenty years ago today … Threads considered harmful … Modelling complex systems … Blood clotting, robots, parrots … 12/3/2020 Copyright P. H. Welch 22

Rapid Review: CSP is a process algebra – a mathematical theory for specifying and verifying patterns of behaviour arising from interactions between concurrent objects. CSP has a formal, and compositional, semantics that is in line with our informal intuition about the way things work. Claim We do not need to be mathematically sophisticated to work with CSP. The sophistication is pre-engineered into the model. We benefit simply by using it. 12/3/2020 Copyright P. H. Welch 23

Rapid Review: CSP encapsulates fundamental principles of communication CSP is semantically defined in terms of a structured mathematical model CSP is sufficiently expressive to enable reasoning about deadlock and livelock CSP has abstraction and refinement central to underlying theory. CSP has robust (and commercially supported) software engineering tools formal verification. 12/3/2020 Copyright P. H. Welch 24

Rapid Review: CSP deals with processes, processes networks of processes and various forms of synchronisation / communication between processes. A network of processes is also a process – so CSP naturally accommodates layered network structures (networks of networks). networks Processes and the necessary synchronisation elements (e. g. channels, channels barriers) barriers can be generated dynamically. So, networks may evolve, combine, split, decay and die … 12/3/2020 Copyright P. H. Welch 25

Processe s n n 12/3/2020 my. process A process is a component that encapsulates some data structures and algorithms for manipulating that data. Both its data and algorithms are private The outside world can neither see that data nor execute those algorithms! [They are not objects …] [Think chips …] The algorithms are executed by the process in its own thread (or threads) of control. Each process is alive So, how does one process interact with another? Copyright P. H. Welch 26

Processe s n n my. process The simplest form of interaction is synchronised messagepassing along channels. The simplest forms of channel are zero-buffered and point-to-point (i. e. wires). wires n But, we can have buffered channels (blocking/overwriting). overwriting n And any-1, 1 -any and any-any channels. n And structured multi-way synchronisation (e. g. barriers) … n And high-level (e. g. CREW) shared-memory locks … 12/3/2020 Copyright P. H. Welch 27

Synchronised Communication A c c ! 42 B c? x A may write on c at any time, but has to wait for a read B may read from c at any time, but has to wait for a write ( A (c) || B (c) ) {c} 12/3/2020 Copyright P. H. Welch 28

Synchronised Communication A c c ! 42 B c? x Only when both A and B are ready can the communication proceed over the channel c. ( A (c) || B (c) ) {c} 12/3/2020 Copyright P. H. Welch 29

Synchronised Communication A n B Benefit u Once n c Careful the writer has written, it knows the reader has read OK: plenty of other processes to run and ultra-fast context switch (comparable to a procedure call) u Writer blocks if reader is not ready u Lots of deadlock possibilities OK: work with (a small set of) synchronisation patterns for which we have proven safety theorems 12/3/2020 Copyright P. H. Welch 30

Simple Deadlock Example A c B d If there is no discipline on when A and B communicate, then A may commit to output on c, followed by B on d … or viceversa. Either way, neither are listening and both are stuck. Same happens if both commit to input. 12/3/2020 Copyright P. H. Welch 31

Client-Server Pattern client request server reply client : makes a request any time, then commits to taking reply server : always accepts a request (within some bounded time), then always makes a reply (within some bounded time). It may make requests itself, as a client to other servers No deadlock is now possible from this client-server relationship. 12/3/2020 Copyright P. H. Welch 32

Client-Server Pattern server client : makes a request any time, then commits to taking reply server : always accepts a request (within some bounded time), then always makes a reply (within some bounded time). It may make requests itself, as a client to other servers Symbology: this represents a client-server relation. It points to the server and allows a 2 -way conversation (initiated by the client) 12/3/2020 Copyright P. H. Welch 33

Client-Server Pattern A server may have many clients … Only one client at a time converses with the server. They form an orderly queue. Still no deadlock possible – and no client starvation. No polling on the queue, so no livelock either. 12/3/2020 Copyright P. H. Welch 34

Client-Server Theorem A client-server system that has no cycles in its client-server relations is deadlock, livelock and starvation free. 12/3/2020 Copyright P. H. Welch 35

Nature is not serial. . . Components must compose … CSP, processes, patterns … It was twenty years ago today … Threads considered harmful … Modelling complex systems … Blood clotting, robots, parrots … 12/3/2020 Copyright P. H. Welch 36

Twenty Years Ago … “… improved understanding and architecture independence were the goals of the design by Inmos of the occam multiprocessing language and the Transputer. The goals were achieved by implementation of the abstract ideas of process algebra and with an efficiency that is today almost unimaginable and certainly unmatchable. ” C. A. R. Hoare, March 2004. 12/3/2020 Copyright P. H. Welch 37

2003 … We have been extending the classical (CSP) occam language with ideas of mobility and dynamic network reconfiguration which are taken from Milner’s -calculus (occam- ). We have found ways of implementing these extensions that still involve significantly less resource overhead than that imposed by the higher level – but less structured, informal and non -compositional – concurrency primitives of existing languages (such as Java) or libraries (such as POSIX threads). 12/3/2020 Copyright P. H. Welch 38

2003 … We have been extending the classical (CSP) occam language with ideas of mobility and dynamic network reconfiguration which are taken from Milner’s -calculus (occam- ). As a result, we can run applications with the order of millions of concurrent processes on modestly powered PCs. We have plans to extend the system, without sacrifice of too much efficiency and none of logic, to simple clusters of workstations, wider networks such as the Grid and small embedded devices. 12/3/2020 Copyright P. H. Welch 39

2003 … In the interests of proveability, we have been careful to preserve the distinction between the original static point-to-point synchronised communication of occam and the dynamic asynchronous multiplexed communication of calculus; in this, we have been prepared to sacrifice the elegant sparsity of the -calculus. We conjecture that the extra complexity and discipline introduced will make the task of developing, proving and maintaining concurrent and distributed programs easier. 12/3/2020 Copyright P. H. Welch 40

Nature is not serial. . . Components must compose … CSP, processes, patterns … It was twenty years ago today … Threads considered harmful … Modelling complex systems … Blood clotting, robots, parrots … 12/3/2020 Copyright P. H. Welch 41

Threads-n-Locks Considered Harmful n n Easy to learn – but very difficult to apply safely … Monitor methods (for example) are tightly interdependent – their semantics compose in exponentially complex ways. The whole skill lies in setting up and staying in control of these complex interactions … Threads have no structure … there are no threads within threads … Big problems when it comes to scaling up complexity … 12/3/2020 Copyright P. H. Welch 42

Threads-n-Locks Considered Harmful Most objects are dead – they have no life of their own. All methods have to be invoked by an external thread of control – they have to be caller oriented … … a somewhat curious property of so-called object oriented design? 12/3/2020 count state ready Copyright P. H. Welch 43

Threads-n-Locks Considered Harmful The object is at the mercy of any thread that sees it. Nothing can be done to prevent method invocation. . . … even if the object is not in a fit state to service it. The object is not in control of its life. 12/3/2020 count state ready Copyright P. H. Welch 44

Threads-n-Locks Considered Harmful Each single thread of control snakes around objects in the system, bringing them to life transiently as their methods are executed. Threads cut across object boundaries leaving spaghetti-like trails, paying no regard to the underlying structure 12/3/2020 Copyright P. H. Welch 45

Threads-n-Locks Considered Harmful Each object is at the mercy of any thread that sees it. Nothing can be done to prevent method invocation … even if the object is not in a fit state to service it. The object is not in control of its life Big problems occur when multiple threads hit the same object. 12/3/2020 Copyright P. H. Welch 46

Threads-n-Locks Considered Harmful Errors in claiming/releasing locks is one of the main reason our systems fail … Too much locking and we get deadlock … Too little locking and race hazards slowly corrupt … Sorting this out requires controlling all possible interleavings … which is exponential in the number of threads … 12/3/2020 Copyright P. H. Welch 47

Threads-n-Locks Considered Harmful Compare this design structure. . . 12/3/2020 Copyright P. H. Welch 48

left right scorer keycontrol . . . against this one Multi. Pong collision detect canvas control new game 12/3/2020 flasher mouse freeze Copyright P. H. Welch 49

Nature is not serial. . . Components must compose … CSP, processes, patterns … It was twenty years ago today … Threads considered harmful … Modelling complex systems … Blood clotting, robots, parrots … 12/3/2020 Copyright P. H. Welch 50

Modelling Bio-Mechanisms n In-vivo In-silico u u u n Modelling technologies u u n One of the UK ‘Grand Challenge’ areas. Move life-sciences from description to modelling / prediction Example: the Nematode worm. Development: from fertilised cell to adult (with virtual experiments). Sensors and movement: reaction to stimuli. Interaction between organisms and other pieces of environment. Communicating process networks – fundamentally good fit. Cope with growth / decay, combine / split (evolving topologies). Mobility and location / neighbour awareness. Simplicity, dynamics, performance and safety. occam- (and JCSP) u u u 12/3/2020 Robust and lightweight – good theoretical support. ~10, 000 processes with useful behaviour in useful time. Enough to make a start … Copyright P. H. Welch 51

n Modelling Nannite. Assemblies TUNA: Theory Underpinning Nanotech Assemblies u u n Implementation Technologies u u n Active nano-devices that manipulate the world at nano-scale to have macroscopic effects (e. g. through assembling artifacts). Need vast numbers of them – but these can grow (exponentially). Need capabilities to design, program and control complex and dynamic networks – build desired artifacts, not undesired ones. Need a theory of dynamic networks and emergent properties. Communicating process networks – fundamentally good fit. Cope with growth / decay, combine / split (evolving topologies). Mobility and location / neighbour awareness. Simplicity, dynamics, performance and safety. York, Surrey and occam- (and JCSP) Kent (2005 -2007) Robust and lightweight – good theoretical support. u ~10, 000 processes with useful behaviour in useful time. u Enough to make a start … u 12/3/2020 Copyright P. H. Welch 52

n Mobility and Location Awareness Classical communicating process applications u u n Static network structures. Static memory / silicon requirements (pre-allocated). Great for hardware design and software for embedded controllers. Consistent and rich underlying theory – CSP Dynamic communicating processes – some questions u u u u 12/3/2020 Mutating topologies: how to keep them safe? Mobile channel-ends and processes: dual notions? Simple operational semantics: low overhead implementation? Yes. Process algebra: combine the best of CSP and the -calculus? Yes. Refinement: for manageable system verification … can we keep? Location awareness: how can mobile processes know where they are, how can they find each other and link up? Programmability: at what level – individual processes or clusters? Overall behaviour: planned or emergent? Copyright P. H. Welch 53

Location (Neighbourhood) Awareness The Matrix Mobile Agents 12/3/2020 Copyright P. H. Welch 54

Location (Neighbourhood) Awareness 12/3/2020 Copyright P. H. Welch 55

Location (Neighbourhood) Awareness 12/3/2020 Copyright P. H. Welch 56

Location (Neighbourhood) Awareness 12/3/2020 Copyright P. H. Welch 57

Mobility and Location Awareness n The Matrix u u n A network of (mostly passive) server processes. Responds to client requests from the mobile agents and, occasionally, from neighbouring server nodes. Deadlock avoided (in the matrix) either by one-place buffered server channels or by pure-client slave processes (one per matrix node) that ask their server node for elements (e. g. mobile agents) and forward them to neighbouring nodes. Server nodes only see neighbours, maintain registry of currently located agents (and, maybe, agents on the neighbouring nodes) and answer queries from local agents (including moving them). The Agents u u 12/3/2020 Attached to one node of the Matrix at a time. Sense presence of other agents – on local or neighbouring nodes. Interact with other local agents – must use agent-specific protocol to avoid deadlock. May decide to reproduce, split or move. Local (or global) sync barriers to maintain sense of time. Copyright P. H. Welch 58

A Thesis and Hypothesis n Thesis u u u n Natural systems are concurrent at all levels of scale. Control is devolved. Central command cannot manage the complexity. Natural systems are complex, robust, efficient, long-lived and continuously evolving. We should take the hint! Natural mechanisms should map on to simple engineering principles with low cost and high benefit. Concurrency is a natural mechanism. We should look on concurrency as a core design mechanism – not as something difficult, used only to boost performance. Computer science took a wrong turn once. Concurrency should not introduce the algorithmic distortions and hazards evident in current practice. It should simplify and hasten the construction, commisioning and maintenance of systems. Hypothesis u 12/3/2020 The wrong turn can be corrected and this correction is needed now. Copyright P. H. Welch 59

Nature is not serial. . . Components must compose … CSP, processes, patterns … It was twenty years ago today … Threads considered harmful … Modelling complex systems … Blood clotting, robots, parrots … 12/3/2020 Copyright P. H. Welch 60

Case Study: blood clotting Haemostasis: we consider a greatly simplified model of the formation of blood clots in response to damage in blood vessels. Platelets are passive quasi-cells carried in the bloodstream. They become activated when a balance between chemical suppressants and activators shift in favour of activation. When activated, they become sticky … We are just going to model the clumping together of such sticky activated platelets to form clots To learn and refine our modelling techniques, we shall start with a simple one-dimensional model of a bloodstream. 12/3/2020 Copyright P. H. Welch 61

Platelet Model (‘lazy’ CA) clot gen ∙∙∙ cell cell ∙∙∙ draw keywatch keyboard 12/3/2020 Copyright P. H. Welch 62

Platelet Model (‘lazy’ CA) clot gen ∙∙∙ cell cell ∙∙∙ draw phase 1 keywatch display screen keyboard 12/3/2020 Copyright P. H. Welch 63

Platelet Model (‘lazy’ CA) clot gen ∙∙∙ cell keywatch cell phase 0 cell display cell ∙∙∙ draw screen keyboard 12/3/2020 Copyright P. H. Welch 64

Platelet Model (‘lazy’ CA) clot gen ∙∙∙ cell keywatch cell display phase 0 cell ∙∙∙ draw screen keyboard 12/3/2020 Copyright P. H. Welch 65

Platelet Model (‘lazy’ CA) clot gen ∙∙∙ cell cell ∙∙∙ draw phase 1 keywatch display screen keyboard 12/3/2020 Copyright P. H. Welch 66

Platelet Model (‘lazy’ CA) clot gen ∙∙∙ cell keywatch cell display phase 0 cell ∙∙∙ draw screen keyboard 12/3/2020 Copyright P. H. Welch 67

Platelet Model (‘lazy’ CA) clot gen ∙∙∙ cell keywatch cell display cell phase 0 cell ∙∙∙ draw screen keyboard 12/3/2020 Copyright P. H. Welch 68

Platelet Model (‘lazy’ CA) clot gen ∙∙∙ cell clot cell ∙∙∙ draw phase 1 keywatch display screen keyboard 12/3/2020 Copyright P. H. Welch 69

Platelet Model (‘lazy’ CA) clot gen ∙∙∙ cell clot cell ∙∙∙ draw phase 1 keywatch display screen keyboard 12/3/2020 Copyright P. H. Welch 70

Platelet Model (‘lazy’ CA) clot gen ∙∙∙ cell clot cell ∙∙∙ draw phase 1 keywatch display screen keyboard 12/3/2020 Copyright P. H. Welch 71

Platelet Model (‘lazy’ CA) clot gen ∙∙∙ cell clot cell ∙∙∙ draw phase 1 keywatch display screen keyboard 12/3/2020 Copyright P. H. Welch 72

Platelet Model (‘lazy’ CA) clot gen ∙∙∙ cell cell ∙∙∙ draw phase 1 keywatch display screen keyboard 12/3/2020 Copyright P. H. Welch 73

Platelet Model (‘lazy’ CA) clot gen ∙∙∙ cell cell ∙∙∙ draw phase 1 keywatch display screen keyboard 12/3/2020 Copyright P. H. Welch 74

Show video … 12/3/2020 Copyright P. H. Welch 75

3 -D Bloodstream 12/3/2020 Copyright P. H. Welch 76

3 -D Bloodstream 12/3/2020 Copyright P. H. Welch 77

3 -D Bloodstream 12/3/2020 Copyright P. H. Welch 78

3 -D Bloodstream 12/3/2020 Copyright P. H. Welch 79

3 -D Bloodstream 12/3/2020 Copyright P. H. Welch 80

3 -D Bloodstream 12/3/2020 Copyright P. H. Welch 81

3 -D Bloodstream 12/3/2020 Copyright P. H. Welch 82

3 -D Bloodstream 12/3/2020 Copyright P. H. Welch 83

3 -D Bloodstream 12/3/2020 Copyright P. H. Welch 84

3 -D Bloodstream 12/3/2020 Copyright P. H. Welch 85

3 -D Bloodstream 12/3/2020 Copyright P. H. Welch 86

3 -D Bloodstream 12/3/2020 Copyright P. H. Welch 87

3 -D Bloodstream 12/3/2020 Copyright P. H. Welch 88

3 -D Bloodstream 12/3/2020 Copyright P. H. Welch 89

3 -D Bloodstream 12/3/2020 Copyright P. H. Welch 90

3 -D Bloodstream 12/3/2020 Copyright P. H. Welch 91

3 -D Bloodstream 12/3/2020 Copyright P. H. Welch 92

3 -D Bloodstream 12/3/2020 Copyright P. H. Welch 93

3 -D Bloodstream 12/3/2020 Copyright P. H. Welch 94

3 -D Bloodstream 12/3/2020 Copyright P. H. Welch 95

3 -D Bloodstream 12/3/2020 Copyright P. H. Welch 96

3 -D Bloodstream 12/3/2020 Copyright P. H. Welch 97

3 -D Bloodstream 12/3/2020 Copyright P. H. Welch 98

Run demos … 12/3/2020 Copyright P. H. Welch 99

n occam- u u u 12/3/2020 Summary – 1 / 2 Combines process and channel mobility (from the –calculus) with the discipline and safety of occam and the composeable and refinement semantics of CSP Even with the new dynamics … what-you-see-is-what-you-get. Overheads for mobiles are still comparable to those for static processes … ~50 ns. ns Potential security benefits for dynamic peer-to-peer networks and agent technologies … to be explored Natural for multi-layer modelling of micro-organisms (or nanobots) and their environments … exploring Compiled codes runs multicore – efficiency looks promising … Semantics for mobile processes and channels – OK. OK We have a mapping down to standard CSP Need a direct theory, though, on which to build more efficient model checkers… to be explored Copyright P. H. Welch 100

Summary – 1 / 2 n The right stuff u u u 12/3/2020 Nature builds robust, complex and successful systems by allowing independent organisms control of their own lives and letting them interact. Central points of control do not remain viable for long Computer (software) engineers should take the hint! Concurrency should be a natural way to design any computer system (or component) above a minimal level of complexity. It should simplify and hasten the construction, commissioning and maintenance of systems; it should not introduce the hazards that are evident in current practice; and it should be employed as a matter of routine Natural mechanisms should map into simple engineering mechanisms with low cost and high benefit To do this requires a paradigm shift in the way we approach concurrency. . . to something much simpler Failure to do this will result in failure to meet the ‘Grand Challenges’ that the 21 st. Century is stacking up for us. Copyright P. H. Welch 101