laws of concurrent design tony hoare microsoft researchcambridge fmcad 2012 23 october

53
Laws of concurrent design Tony Hoare Microsoft Research Cambridge FMCAD 2012 23 October

Upload: stuart-york

Post on 13-Dec-2015

220 views

Category:

Documents


1 download

TRANSCRIPT

Page 1: Laws of concurrent design Tony Hoare Microsoft ResearchCambridge FMCAD 2012 23 October

Laws of concurrent design

Tony HoareMicrosoft Research Cambridge

FMCAD 2012 23 October

Page 2: Laws of concurrent design Tony Hoare Microsoft ResearchCambridge FMCAD 2012 23 October

Summary

• What are they?• Are they useful?• Are they true?• Are they beautiful?

Page 3: Laws of concurrent design Tony Hoare Microsoft ResearchCambridge FMCAD 2012 23 October

1. Laws

Page 4: Laws of concurrent design Tony Hoare Microsoft ResearchCambridge FMCAD 2012 23 October

Subject matter• (traces of) execution of a program – recording a set of events, – occurring inside and near a computer– while it is executing a program

• specifications/designs/programs– describing sets of traces– that are desired/planned/actual– when the program is executed

• the same laws will apply to both.

Page 5: Laws of concurrent design Tony Hoare Microsoft ResearchCambridge FMCAD 2012 23 October

Three operators• then ; sequential composition• with || concurrent composition• skip I does nothing

Page 6: Laws of concurrent design Tony Hoare Microsoft ResearchCambridge FMCAD 2012 23 October

Five Axioms

• assoc p;(q;r) = (p;q);r (also ||)• comm p||q = q||p• unit p||I = p = I||p (also ;)

Page 7: Laws of concurrent design Tony Hoare Microsoft ResearchCambridge FMCAD 2012 23 October

Reversibility

• assoc p;(q;r) = (p;q);r (also ||)• comm p||q = q||p• unit p||I = p = I||p (also ;)

• swapping the order of operands of ; (or of ||) translates each axiom into itself.

Page 8: Laws of concurrent design Tony Hoare Microsoft ResearchCambridge FMCAD 2012 23 October

Duality

• Metatheorem: (theorems for free)When a theorem is translated by reversing the operands of all ;s (or of all ||s), the result is also a theorem.

• Many laws of physics are also reversible in the direction of time

Page 9: Laws of concurrent design Tony Hoare Microsoft ResearchCambridge FMCAD 2012 23 October

Comparison: p => q

• Example: refinement – every trace described by p is also described by q

• Example: definement (Scott ⊑)– if the trace p is defined it is equal to the trace q

Page 10: Laws of concurrent design Tony Hoare Microsoft ResearchCambridge FMCAD 2012 23 October

Axiom

• => is a partial order– reflexive p => p– transitive if p => q & q => r then p => r

• swapping the operands of => translates each axiom into itself• justifies duality by order reversal

Page 11: Laws of concurrent design Tony Hoare Microsoft ResearchCambridge FMCAD 2012 23 October

Monotonicity

• Definition: an operator is monotonic if– p => q implies pr => qr & rp => rq

• Axiom: ; and || are monotonic

• justifies replacement of any component of a term by one that is more refined/defined

Page 12: Laws of concurrent design Tony Hoare Microsoft ResearchCambridge FMCAD 2012 23 October

Monotonicity

• Metatheorem :Let F be a formula containing p.Let F’ be a translation of F that replaces an occurrence of p by qLet p => q be a theorem--------------------------------------------------------Then F(p) => F’(q) is also a theorem

Page 13: Laws of concurrent design Tony Hoare Microsoft ResearchCambridge FMCAD 2012 23 October

Exchange Axiom

• (p||q) ; (p’||q’) => (p;p’) || (q;q’)

• Theorem (frame): (p||q) ; q’ => p||(q;q’)– Proof: substitute for p’ in exchange axiom

• Theorem: p;q => p*q

• This axiom is self-dual by time-reversal

Page 14: Laws of concurrent design Tony Hoare Microsoft ResearchCambridge FMCAD 2012 23 October

2. Applications

Page 15: Laws of concurrent design Tony Hoare Microsoft ResearchCambridge FMCAD 2012 23 October

The laws are useful

• for proof of correctness of programs/designs– by means of Hoare logic– extended by concurrent separation logic.

• for design/proof of implementations– using Milner transitions– extended by sequential composition.

Page 16: Laws of concurrent design Tony Hoare Microsoft ResearchCambridge FMCAD 2012 23 October

The Hoare triple

• Definition: {p} q {r} = p;q => r– If p describes what has happened so far– and q is then executed to completion,– the overall result will satisfy r.

Page 17: Laws of concurrent design Tony Hoare Microsoft ResearchCambridge FMCAD 2012 23 October

The rule of composition

• Definition: {p} q {r} = p;q => r• Theorem:

{p} q {s} {s} q’ {r} {p} q;q’ {r}

Page 18: Laws of concurrent design Tony Hoare Microsoft ResearchCambridge FMCAD 2012 23 October

Proof

• Definition: {p} q {r} = p;q => r• expanding the definition:

p;q => s s;q’ => r p;q;q’ => r

because ; is monotonic and associative

Page 19: Laws of concurrent design Tony Hoare Microsoft ResearchCambridge FMCAD 2012 23 October

Modularity rule for ||

• in concurrent separation logic

{p} q {r} {p’} q’ {r’} {p||p’} q||q’ {r||r’}

– permits modular proof of concurrent programs.

• it is equivalent to the exchange law

Page 20: Laws of concurrent design Tony Hoare Microsoft ResearchCambridge FMCAD 2012 23 October

Modularity rule implies Exchange law

• By reflexivity: p;q => p;q and p’;q’ => p’;q’• Exchange is the conclusion of modularity rule

(p||p’) ; (q||q’) => (p;q) || (p’;q’)

Page 21: Laws of concurrent design Tony Hoare Microsoft ResearchCambridge FMCAD 2012 23 October

Exchange law implies modularity

• Assume: p;q => r and p’;q’ => r’• monotonicity of || gives

(p;q) || (p’;q’) => r|| r’• the Exchange law says

(p||p’) ; (q||q’) => (p;q) || (p’;q’)• by transitivity:

(p||p’) ; (q||q’) => r||r’which is the conclusion of the modularity rule

Page 22: Laws of concurrent design Tony Hoare Microsoft ResearchCambridge FMCAD 2012 23 October

Frame Rules

{p} q {r}{p||f} q {r||f}

– adapts a triple to a concurrent environment f– proof: from frame theorem

{p} q {r}__ {f;p} q {f;r}– proof: mon, assoc of ;

Page 23: Laws of concurrent design Tony Hoare Microsoft ResearchCambridge FMCAD 2012 23 October

The Milner triple: r - q -> p

• defined as q;p => r – the time reversal of {p} q {r}– r may be executed by first executing q – with p as continuation for later execution.• maybe there are other ways of executing r

• Tautology: (q ; p) – q -> p• Proof: from reflexivity: q;p => q;p

Page 24: Laws of concurrent design Tony Hoare Microsoft ResearchCambridge FMCAD 2012 23 October

Technical Objection

• Originally, Hoare restricted q to be a program, and p , r to be state descriptions

• Originally, Milner restricted p and r to be programs, and q to be an atomic action.

• These restrictions are useful in application.• And so is their removal • (provided that the axioms are still consistent).

Page 25: Laws of concurrent design Tony Hoare Microsoft ResearchCambridge FMCAD 2012 23 October

Sequential composition

{p} q {s} {s} q’ {r} {p} q;q’ {r}

r –q-> s s –q’-> p r –(q;q’)-> p

Proof: by reversal of the Hoare rule

Page 26: Laws of concurrent design Tony Hoare Microsoft ResearchCambridge FMCAD 2012 23 October

Concurrency in CCS

r –p-> q r’ -p’-> q’ (r||r’) -(p||p’)-> (q||q’)

– provided p||p’ = τ– where τ is the unobserved atomic transition,which occurs (in CCS) when p and p’ are an input and an output on the same channel.

• Proof: by reversal of the modularity rule

Page 27: Laws of concurrent design Tony Hoare Microsoft ResearchCambridge FMCAD 2012 23 October

Frame Rules

r –q-> p(r||f) –q-> (p||f)

– a step q possible for a single thread r is still possible when r is executed concurrently with f

r –q-> p (r;f) –q->(p;f) – operational definition of ;

Page 28: Laws of concurrent design Tony Hoare Microsoft ResearchCambridge FMCAD 2012 23 October

The internal step

• r -> p = def. p => r– (the order dual of refinement)– the implementation may make a refinement step– reducing the range of subsequent behaviours

Page 29: Laws of concurrent design Tony Hoare Microsoft ResearchCambridge FMCAD 2012 23 October

Rule of consequence

• p => p’ {p’} q {r’} r’ => r{p} q {r}

• r -> r’ r’ –q-> p’ p’ -> pr –q-> p

– Proof: ; is monotonic and associative, – => is transitive.

• Each rule is the dual of the other– by order reversal and time reversal

Page 30: Laws of concurrent design Tony Hoare Microsoft ResearchCambridge FMCAD 2012 23 October

Additional operators

• p \/ q describes all traces of p and all of q– describes options in design– choice (non-determinism) in execution

• p /\ q describes all traces of both p and q– conjunction of requirements (aspects) in design– lock-step concurrency in execution

Page 31: Laws of concurrent design Tony Hoare Microsoft ResearchCambridge FMCAD 2012 23 October

Axioms

• /\ is the disjunction and \/ is the conjunction of a Boolean Algebra (even with negation).

• Axiom: ; and || distribute through \/– which validates reasoning by cases– and implementation by non-deterministic

selection

Page 32: Laws of concurrent design Tony Hoare Microsoft ResearchCambridge FMCAD 2012 23 October

Choice

• {p} q {r} {p} q’ {r} {p} (q \/ q’) {r}

– both choices must be correct– proof: distribution of ; through \/

___r –q-> p____ (r \/ r’) –q-> p– only one of the alternatives is executed– proof: r => r \/ r’

Page 33: Laws of concurrent design Tony Hoare Microsoft ResearchCambridge FMCAD 2012 23 October

Axioms proved from calculi

from Hoare• p ; (q\/r) => p;q \/ p;r• p;r \/ q;r => (p\/q) ; r

from Milner• (p\/q) ; r => (p;r) \/ (q;r)• p;q \/ p;r => p ; (q\/r)

from both• p ; (q;r) => (p;q) ; r• (p;q) ; r => p ; (q;r)• exchange law

Page 34: Laws of concurrent design Tony Hoare Microsoft ResearchCambridge FMCAD 2012 23 October

Message

• Both the Hoare and Milner rules are derived from the same algebra of programming.

• The algebra is simpler than each of the calculi,

• and stronger than both of them combined.

• They are mutually consistent, provided the laws are true

Page 35: Laws of concurrent design Tony Hoare Microsoft ResearchCambridge FMCAD 2012 23 October

3. The laws are true

Page 36: Laws of concurrent design Tony Hoare Microsoft ResearchCambridge FMCAD 2012 23 October

The laws are true of…

• specifications, designs, implementations of– programs– hardware– networks– hybrid systems– the real world of events

occurring in space and time

Page 37: Laws of concurrent design Tony Hoare Microsoft ResearchCambridge FMCAD 2012 23 October

Happens before ()

• Let e, f, g є Ev (a set of event occurrences).

• Let e f mean (your choice of) :

– ‘the occurrence e was/will be an immediate and necessary cause of the occurrence f ’

– ‘the occurrence f directly depends (depended) on the occurrence e ’

– ‘e happens before f ’ ‘f happens after e ’

Page 38: Laws of concurrent design Tony Hoare Microsoft ResearchCambridge FMCAD 2012 23 October

Example: hardware

• a rising edge next falling edge on same wire

• a rising edge rising edge on another wire

Page 39: Laws of concurrent design Tony Hoare Microsoft ResearchCambridge FMCAD 2012 23 October

Example: Petri nets

e f , f’ g

e f , f’ g

e f

gf’

Page 40: Laws of concurrent design Tony Hoare Microsoft ResearchCambridge FMCAD 2012 23 October

Message sequence charts

sqlapp net

Page 41: Laws of concurrent design Tony Hoare Microsoft ResearchCambridge FMCAD 2012 23 October

Examples: software

• nth output nth input (on reliable channel)

• nth V nth P

(on an exclusion semaphore)

• nth assignment read of nth value

(of a variable in memory)

• read of nth value (n + 1)st assignment (in strong memory) 

Page 42: Laws of concurrent design Tony Hoare Microsoft ResearchCambridge FMCAD 2012 23 October

Precedes

• Define < as ()*

– the reflexive transitive closure

• Define > as <

– the converse of <

• Examples:

– allocation of a resource < any use of it

– disposal of a resource > any use of it

Page 43: Laws of concurrent design Tony Hoare Microsoft ResearchCambridge FMCAD 2012 23 October

Interpretations

• e < f & f < e means– e and f are (part of) the same atomic action

– or there is deadlock

• not e < f & not f < e means– e and f are independent of each other

– their executions may overlap in time,

– or one may complete before the other starts

Page 44: Laws of concurrent design Tony Hoare Microsoft ResearchCambridge FMCAD 2012 23 October

Cartesian product

• Let p, q, r Ev

– traces of execution

• Define p × q = {(e,f) | e p & f q }

– cartesian product

• Theorem: p × (q r) = p×q p×r

(q r) × p = q×p r×p

Page 45: Laws of concurrent design Tony Hoare Microsoft ResearchCambridge FMCAD 2012 23 October

Composition

• Let p, q, r Ev (traces of execution)

• Let seq Ev × Ev (arbitrary relation)

• Define p;q = p q if p × q seq

& p, q are defined

– and is undefined otherwise

Theorem: ; is monotonic

– with respect to definement ordering

Page 46: Laws of concurrent design Tony Hoare Microsoft ResearchCambridge FMCAD 2012 23 October

Theorem: (p ; q) ; r = p ; (q ; r)

• Proof: when they are both defined, each side is equal to ( p q r ).

LHS is defined (by definition of ;)

p × q seq & (p q) × r seq (by × distrib )

p × q seq & p × r seq & q × r seq p × (q r) seq & q × r seq

RHS is defined

Page 47: Laws of concurrent design Tony Hoare Microsoft ResearchCambridge FMCAD 2012 23 October

Sequential composition

• Define seq = <

• Then p;q is strong sequential composition

• means that p must finish before q starts

– all events in p precede all events in q

• Example: Ev is NN

– {1, 7, 19} ; {21, 32} = {1, 7, 19, 21, 32}

– {1, 7, 19} ; {19, 32} is undefined

Page 48: Laws of concurrent design Tony Hoare Microsoft ResearchCambridge FMCAD 2012 23 October

Sequential composition

• Define seq = not >

• Then p;q is weak sequential composition

• means that p may finish before q begins

– note that q may start before p finishes

– with events that are independent of p

– just as in your computer today

Page 49: Laws of concurrent design Tony Hoare Microsoft ResearchCambridge FMCAD 2012 23 October

Concurrent Composition

Define par = seq seq

Note: seq par = par

Define p||q = p q if p × q par and p, q defined

Theorem: || is associative and commutative.

Strong || is interleaving.

Weak || avoids deadlocks

Page 50: Laws of concurrent design Tony Hoare Microsoft ResearchCambridge FMCAD 2012 23 October

• Proof: when LHS is defined, it equals RHS

LHS defined q × q’ par & r × r’ par

& (q q’) × (r r’) seq

q × q’ r × r’ par

& q’ × r’ q × r q’ × r q × r’ seq

q’ × r’ seq & q × r seq

& (q r) × (q’ r’) par

RHS defined.

(q || q’) ; (r || r’)=> (q ; r ) || (q’ ; r’)

Page 51: Laws of concurrent design Tony Hoare Microsoft ResearchCambridge FMCAD 2012 23 October

Interleaving

• Strong.• {1, 7, 9}||{3, 12} = {1, 3, 7, 9, 12}

Page 52: Laws of concurrent design Tony Hoare Microsoft ResearchCambridge FMCAD 2012 23 October

4. Conclusion

The laws are usefulThe laws are true

Page 53: Laws of concurrent design Tony Hoare Microsoft ResearchCambridge FMCAD 2012 23 October

The Laws

• The laws are useful– they shorten formulae, theorems, proofs– they prove consistency of proof rules – with the implementation

• The laws are true– of specifications, designs, products– hardware/software/the real world

• The laws are beautiful