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

1

Software Architecture

Bertrand Meyer

ETH Zurich, March-May 2009

Lecture 15: Designing for concurrency& real-time

The world is increasingly concurrent

ProcessesNetworking, the Internet, the WebMultithreadingMulticore 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 sequentialRisks:

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 + 1y := x + y + 1{x = 1, y = 2}

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

{x = ?, y = ?}

77

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 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”

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 exampleSource: 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 = xold + 1) (y = yold))) ( ((Y = Yold + 1) (x = xold)))

)

Possible implementationx := 0 ; y := 0parallel

forever x := x + 1 end ||forever y := y + 1 end

end

From an example by Lamport

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”

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

1818

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)

requirenot x is_full

do … end

20

Dining philosophers

class PHILOSOPHER inheritPROCESS

rename setup as getupredefine step end

feature {BUTLER}step

do think ; eat (left, right)

end

eat (l, r : separate FORK) -- Eat, having grabbed l and r.

do … endend

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 PP П P | -- Internal choiceP P | -- External choiceP || P | -- ConcurrencyP ||| P | -- InterleavingP \ H | -- Hiding (H: alphabet

symbols)mP f (P) -- Recursion

26

Some examples

CLOCK = (tick CLOCK)

This is an abbreviation forCLOCK = 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 || PP || (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 П PP П (Q П R) = (P П Q) П Rx (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))

Designing concurrent systems

The basic advice today:Keep the concurrency aspectsseparate from the other architectural

constraints

Software architecture

DesignPatternsComponentsArchitectural styles

The key is to find the right abstractions