Software Architecture

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

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

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

4. 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.” • SeeJohn Markoff, Faster Chips Are Leaving Programmers in Their Dust, New York Times, 17 Dec. 2007

5. 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

6. 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. store (b: [G ] ; v: G) -- Store v into b. require not b.is_full do … ensure notb.is_empty end put my_queue :[T ] … ifnot my_queue.is_full then store (my_queue, t ) end QUEUE BUFFER item, remove QUEUE BUFFER

8. Architectural models • Three general styles: • Shared memory • Message passing • Event-driven

9. Three kinds of desirable properties • Safety: no undesiredsituation will arise “No two lights will begreen at the same time” • Liveness: there will alwaysbe an applicable event “Some light will turngreen” Fairness: every applicable event will happen after finite time “If there is at least one car waiting, the light will turn green”

10. 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

11. 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

12. Statechart example Source: B. Powel-Douglass

13. Temporal logic • Logic plus new operators: • □ffholds now and rest of execution • ◊ ffholds sometime from now on • ffholds at the next state • f U gfholds until when and ifgholds

14. Example temporal logic specification From an example by Lamport • (x = 0) (y = 0)  • □ ( • ( ((x = xold+ 1) (y = yold)))  • ( ((Y = Yold+ 1) (x = xold))) • ) • Possible implementation • x := 0 ; y := 0 • parallel • foreverx := x + 1end|| • forevery := y + 1end • end

15. Three kinds of real-time properties • Safety: no undesiredsituation will arise “No two lights will begreen at the same time” • Liveness: there will alwaysbe an applicable event “Some light will turngreen” Fairness: every applicable event will happen after finite time “If there is at least one car waiting, the light will turn green”

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

17. 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 notb.is_empty end put my_queue:[T ] … ifnot my_queue.is_full then store (my_queue, t) end QUEUE BUFFER item, remove QUEUE BUFFER

19. 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 PHILOSOPHERinherit • PROCESS • rename • setupasgetup • redefinestep end • feature {BUTLER} • step • do • think ;eat (left, right) • end • eat (l, r: separateFORK) • -- Eat, having grabbed land r. • do … end • end

21. 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) • a(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) • mPf (P) -- Recursion

26. Some examples • CLOCK = (tick  CLOCK) • This is an abbreviation for • CLOCK = mP(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 = • mP(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 || STOPaP = STOPaP • (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 = mX((a  X) П(b  X)) • Q = (mX(a  X)) П(mX(b  X))

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

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