1 Software Architecture Bertrand Meyer ETH Zurich, March-May 2009 Lecture 15: Designing for concurrency & real-time

The world is increasingly concurrent Processes Networking, the Internet, the Web Multithreading Multicore computing

Clock speed flattening sharply Transistor count still rising Moore’s law (source: M. Herlihy)

Statements about concurrency Intel: “Multi-core processing is taking the industry on a fast-moving and exciting ride into profoundly new territory. The defining paradigm in computing performance has shifted inexorably from raw clock speed to parallel operations and energy efficiency”. Rick Rashid, head of Microsoft Research “Multicore processors represent one of the largest technology transitions in the computing industry today, with deep implications for how we develop software.” Bill Gates: “Multicore: This is the one which will have the biggest impact on us. We have never had a problem to solve like this. A breakthrough is needed in how applications are done on multicore devices.” See John Markoff, Faster Chips Are Leaving Programmers in Their Dust, New York Times, 17 Dec. 2007

Why is concurrency hard? Ordinary modes of reasoning are sequential Risks:  Data race  Deadlock  Starvation Testing and debugging are harder (some say impossible) Plus, for “hard-real-time” systems, the difficulty of guaranteeing response times and memory occupation

Example {x = 0, y = 0} x := x + 1 y := x + y + 1 {x = 1, y = 2} {x = 0, y = 0} x := x + 1 y := x + y + 1 {x = 1, y = 2} {x = ?, y = ?}

7 7 store (b : [G ] ; v : G ) -- Store v into b. require not b. is_full do … ensure not b. is_empty end QUEUE BUFFER my_queue : [T ] … if not my_queue. is_full then store (my_queue, t ) end BUFFER QUEUE put item, remove

Architectural models Three general styles:  Shared memory  Message passing  Event-driven

Three kinds of desirable properties Safety: no undesired situation will arise “No two lights will be green at the same time” Liveness: there will always be an applicable event “Some light will turn green” Fairness: every applicable event will happen after finite time “If there is at least one car waiting, the light will turn green”

Concurrency frameworks 1. Low-level mechanisms, e.g. threading libraries 2. Graphical models 3. Concurrent extensions to modern programming languages, e.g. SCOOP 4. Process calculi

Statecharts (UML) Finite-state machine for describing behavior of reactive systems Events cause transitions between states. They can have:  Parameters  Guards  Actions  Time values Kinds of events:  SignalEvent: asynchronous, queued  CallEvent: synchronous, blocks sender  ChangeEvent: occurs when state value changes  TimeEvent: associated with timeout

Statechart example Source: B. Powel-Douglass

Temporal logic Logic plus new operators: □ f f holds now and rest of execution ◊ f f holds sometime from now on  f f holds at the next state f U g f holds until when and if g holds

Example temporal logic specification (x = 0)  (y = 0)  □ ( (  ((x = x old + 1)  (y = y old )))  (  ((Y = Y old + 1)  (x = x old ))) ) Possible implementation x := 0 ; y := 0 parallel forever x := x + 1 end || forever y := y + 1 end end From an example by Lamport

Three kinds of real-time properties Safety: no undesired situation will arise “No two lights will be green at the same time” Liveness: there will always be an applicable event “Some light will turn green” Fairness: every applicable event will happen after finite time “If there is at least one car waiting, the light will turn green”

Three kinds of real-time properties Safety: no undesired situation will arise “No two lights will be green at the same time” Liveness: there will always be an applicable event “Some light will turn green” Fairness: every applicable event will happen after finite time “If there is at least one car waiting, the light will turn green” □ ( green1 + green2 + green3 <= 1) ◊ ( green1 + green2 + green3 = 1) car1  ◊ green1  car2  ◊ green2  car3  ◊ green3

The SCOOP model Aim: smallest possible extension of sequential object- oriented model, preserving classical modes of reasoning

18 store (b : [G ] ; v : G ) -- Store v into b. require not b. is_full do … ensure not b. is_empty end QUEUE BUFFER my_queue : [T ] … if not my_queue. is_full then store (my_queue, t ) end BUFFER QUEUE put item, remove

SCOOP principles Each object is handled by a “processor” Object handled by different processor is specially declared: x: separate T Passing separate values as arguments locks them: p (sep_x, sep_y) Preconditions serve as wait conditions: p (x, y: separate T) require not x is_full do … end

20 Dining philosophers class PHILOSOPHER inherit PROCESS rename setup as getup redefine step end feature {BUTLER} step do think ; eat (left, right) end eat (l, r : separate FORK) -- Eat, having grabbed l and r. do … end end

The calculi CSP (Hoare) CCS, Pi-calculus (Milner) Aim: provide a formal basis for reasoning about concurrent systems

22 CSP origins Communicating Sequential Processes: C.A.R. Hoare 1978 paper, based in part on ideas of E.W. Dijkstra (guarded commands, 1978 paper and “A Discipline of Programming” book) Revised with help of S. D. Brooks and A.W. Roscoe 1985 book, revised 2004

23 CSP purpose Concurrency formalism  Expresses many concurrent situations elegantly  Influenced design of several concurrent programming languages, in particular Occam (Transputer) Calculus  Formally specified: laws  Makes it possible to prove properties of systems

24 Basic notions Processes engage in events Example: BDVM = (coin  coffee  coin  coffee  STOP)  (BDVM) = {coin, coffee} u

25 Basic CSP syntax P ::= Stop |-- Does not engage in any events a  P |-- Accepts a, then engages in P P П P|-- Internal choice P  P|-- External choice P || P|-- Concurrency P ||| P|-- Interleaving P \ H|-- Hiding (H: alphabet symbols)  P f (P)-- Recursion

26 Some examples CLOCK = (tick  CLOCK) This is an abbreviation for CLOCK =  P (tick  P) CVM= (in1f  (coffee  CVM)) = (in1f  coffee  CVM)-- Right-associativity CHM1 = (in1f  out50rp  out20rp  out20rp  out10rp) CHM2 = (in1f  out50rp  out50rp) CHM = CHM1 П CHM2

27 More examples COPYBIT = (in.0  out.0  COPYBIT  in.1  out.1  COPYBIT)

28 More examples VMC = (in2f  ((large  VMC)  (small  out1f  VMC))  (in1f  ((small  VMC)  (in1f  large  VMC)) FOOLCUST = (in2f  large  FOOLCUST  in1f  large  FOOLCUST) FOOLCUST || VMC =  P (in2f  large  P  in1f  STOP)

29 Internal non-deterministic choice CH1F = (in1f  ((out20rp  out20rp  out20rp  out20rp  out20rp  CH1F) П (out50rp  out50rp  CH1F)))

30 Laws of concurrency P || Q = Q || P P || (Q || R)) = ((P || Q) || R) P || STOP  P = STOP  P (c  P) || (c  Q) = (c  (P || Q)) (c  P) || (d  Q) = STOP-- If c ≠ d (x: A  P (x)) || (y: B  Q (y)) = (z: (A  B)  (P (z) || Q (z))

31 Laws of non-deterministic internal choice P П Q = Q П P P П ( Q П R) = (P П Q) П R x  (P П Q) = (x  P) П ( x  Q) P || ( Q П R) = (P || Q) П (P || R ) (P || Q) П R = (P || R) П (Q || R ) The recursion operator is not distributive; consider: P =  X ((a  X) П ( b  X)) Q = (  X (a  X)) П (  X (b  X))

Designing concurrent systems The basic advice today: Keep the concurrency aspects separate from the other architectural constraints

Software architecture Design Patterns Components Architectural styles The key is to find the right abstractions