1 / 97

Algebra of Concurrent Programming

Algebra of Concurrent Programming. Tony Hoare Cambridge 2011. With ideas from. Ian Wehrman John Wickerson Stephan van Staden Peter O’Hearn Bernhard Moeller Georg Struth Rasmus Petersen …and others. Subject matter: designs.

iden
Télécharger la présentation

Algebra of Concurrent Programming

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  1. Algebra of Concurrent Programming Tony Hoare Cambridge2011

  2. With ideas from • Ian Wehrman • John Wickerson • Stephan van Staden • Peter O’Hearn • Bernhard Moeller • Georg Struth • Rasmus Petersen • …and others

  3. Subject matter: designs • variables (p, q, r) stand for computer programs, designs, specifications,… • they all describe what happens inside/around a computer that executes a given program. • The program itself is the most precise. • The specification is the most abstract. • Designs come in between.

  4. Examples • Postcondition: • execution ends with array A sorted • Conditional correctness: • if execution ends, it ends with A sorted • Precondition: • execution starts with x even • Program: x := x+1 • the final value of x one greater than the initial

  5. Examples • Safety: • There are no buffer overflows • Termination: • execution is finite (ie., always ends) • Liveness: • no infinite internal activity (livelock) • Fairness: • a response is always given to each request • Probability: • the ration of a’s to b’s tends to 1 with time

  6. Unification • Same laws apply to programs, designs, specifications • Same laws apply to many forms of correctness. • Tools based on the laws serve many purposes. • Distinctions can be drawn later • when the need for them is apparent

  7. Refinement: p ⊑ q • Everything described by p is also described by q , e.g., • spec p implies spec q • prog p satisfies spec q • prog p more determinate than prog q • stepwise development of a spec is • spec ⊒ design ⊒ program • stepwise analysis of a program is • program ⊑ design ⊑ spec

  8. Various terminology p ⊑ q • below • lesser • stronger • lower bound • more precise • …deterministic • included in  • antecedent => • above • greater • weaker • upper bound • more abstract • ...non-deterministic • containing (sets) • consequent (pred)

  9. Law: ⊑ is a partial order • ⊑ is transitive • p ⊑ r if p ⊑ q and q ⊑ r • needed for stepwise development/analysis • ⊑ is antisymmetric • p = r if p ⊑ r and r ⊑ p • needed for abstraction • ⊑ is reflexive • p ⊑ p • for convenience

  10. Binary operator: p ; q • sequential composition of p and q • eachexecution of p;q consists of • all events x from an execution of p • and all events y from an execution of q • subject to ordering constraint, either • strong -- weak • interruptible -- inhibited

  11. alternative constraints on p;q • strong sequence: • all x from p must precede all y from q • weak sequence: • no y from q can precede any x from p • interruptible: • other threads may interfere between x and y • separated: • updates to private variables are protected. • all our algebraic laws will apply to each alternative

  12. Hoare triple: {p} q {r} • defined as p;q ⊑ r • starting in the final state of an execution of p, q ends in the final state of some execution of r • p and r may be arbitrary designs. • example: {..x+1 ≤ n} x:= x + 1 {..x ≤ n} • where ..b (finally b) describes all executions that end in a state satisfying a single-state predicate b .

  13. monotonicity • Law: ( ; is monotonic wrto ⊑) : • p;q ⊑ p’;qif p ⊑ p’ • p;q⊑ p;q’ if q ⊑ q’ • compare: addition of numbers • Rule (of consequence): • p’ ⊑ p & {p} q {r} & r ⊑ r’ implies {p’} q {r’} • Rule is interprovable with first law

  14. associativity • Law (; is associative) : • (p;q);q’ = p;(q;q’) • Rule(sequential composition): • {p} q {s} & {s} q’ {r} implies{p} q;q’ {r} • half the law interprovablefrom rule

  15. Unit(skip):  • a program that does nothing • Law ( is the unit of ;): • p;= p = ;p • Rule(nullity) • {p}  {p} • a quarter of the law is interprovablefrom Rule

  16. concurrent composition: p | q • each execution of (p|q) consists of • all events x of an execution of p, • and all events y of an execution of q • same laws apply to alternatives: • interleaving: x precedes or follows y • true concurrency: x neither precedes nor follows y. • separation: x and y independent • Laws: | is associative, commutative and monotonic

  17. Separation Logic • Law (locality of ; wrto |): • (s|p) ; q ⊑ s |(p;q) (left locality ) • p ; (q|s) ⊑ (p;q) | s (right locality) • Rule(frame) : • {p} q {r} implies {p|s} q {r|s} • Rule interprovable withleft locality

  18. Concurrency law • Law (; exchanges with *) • (p|q) ; (p’|q’) ⊑ (p;p’) | (q;q’) • like exchange law of category theory • Rule(| compositional) • {p} q {r} & {p’} q’ {r’} implies {p|p’} q|q’ {r|r’} • Rule interprovable withthe law

  19. p|q;p’|q’ p p’ q q’ by columns

  20. p|q;p’|q’ ⊑ p p’ p;p’ |q;q’ q q’ by rows

  21. Regular language model • p, q, r,… are languages • descriptions of execution of fsm. • p ⊑ q is inclusion of languages • p;q is (lifted) concatenation of strings • i.e., {st| s ∊ p & t ∊ q} • p|q is (lifted) interleaving of strings •  = {< >} (only the empty string) • “c” = {<c>} (only the string “c”)

  22. Left locality • Theorem: (s|p) ; q ⊑ s | (p;q) • Proof: in lhs: s interleaves with just p , and all of q comes at the end. in rhs: s interleaves with all of p;q so lhs is a special case of rhs • p s s ; q qq ⊑ p s q s q q

  23. Exchange • Theorem: (p|q) ; (p’|q’) ⊑ (p;p’) | (q;q’) • in lhs: all of p and q comes before all of p’ and q’ . • in rhs: end of p may interleave with q’ or start of p’ with q the lhs is a special case of the rhs. p q p ; q’ p’ q’ ⊑ p q q’ p p’ q’

  24. Conclusion • regular expressions satisfy all our laws for ⊑ , ; , and | • and for other operators introduced later

  25. Part 2. More Program Control Structures • Non-determinism, intersection • Iteration, recursion, fixed points • Subroutines, contracts, transactions • Basic commands

  26. Subject matter • variables (p, q, r) stand for programs, designs, specifications,… • they are all descriptions of what happens inside and around a computer that is executing a program. • the differences between programs and specs are often defined from their syntax.

  27. Specification syntax includes • disjunction (or, ⊔) to express abstraction, or to keep options open • ‘it may be painted green or blue’ • conjunction (and, ⊓) combines requirements • it must be cheaper than x and faster than y • negation (not) for safety and security • it must not explode • implication (contracts) • if the user observes the protocol, so will the system

  28. Program syntax excludes • disjunction • non-deterministic programs difficult to test • conjunction • inefficient to find a computation satisfying both • negation • incomputable • implication • which side of contract?

  29. programs include • sequential composition (;) • concurrent composition (|) • interrupts • iteration, recursion • contracts (declarations) • transactions • assignments, inputs, outputs, jumps,… • So include these in our specifications!

  30. Bottom  • An unimplementable specification • like the false predicate • A program that has no execution • the compiler stops it from running • Define  as least solution of: _ ⊑ _ • Theorem:  ⊑ r •  satisfies every spec, • but cannot be run (Dijkstra’s miracle)

  31. Algebra of  • Law ( is the zero of ;) : •  ; p =  = p ;  • Theorem : {p}  {q} • Quarter of law provable from theorem

  32. Top ⊤ • a vacuous specification, • satisfied by anything, • like the predicate true • a program with an error • for which the programmer is responsible • e.g., subscript error, violation of contract… • define ⊤ as greatest solution of: _ ⊑ _

  33. Algebra of ⊤ • Law: none • Theorem: none • you can’t prove a program with this error • it might admit a virus! • A debugging implementation may supply useful laws for ⊤

  34. Non-determinism (or): p ⊔ q • describes all executions that either satisfy p or satisfy q . • The choice is not (yet) determined. • It may be determined later • in development of the design • or in writing the program • or by the compiler • or even at run time

  35. lub (join): ⊔ • Define p⊔q as least solution of p ⊑ _ & q ⊑ _ • Theorem • p ⊑ r & q ⊑ r iffp⊔q⊑ r • Theorem • ⊔ is associative, commutative, monotonic, idempotent and increasing • it has unit ⊥ and zero ⊤

  36. glb (meet): ⊓ • Define p⊓qas greatest solution of _ ⊑ p & _ ⊑ q

  37. Distribution • Law ( ; distributive through ⊔ ) • p ; (q⊔q’) = p;q ⊔ p;q’ • (q⊔q’) ; p = q;p⊔ q’;p • Rule(non-determinism) • {p} q {r} & {p} q’ {r} implies {p} q⊔q’ {r} • i.e., to prove something of q⊔q’ prove the same thing of both q and q’ • quarter of law interprovable with rule

  38. Conditional: p if b else p’ • Define p ⊰b⊱ p’ as b.. ⊓ p ⊔ not(b).. ⊓ p’ • where b.. describes all executions that begin in a state satisfying b . • Theorem. p ⊰b⊱ p’ is associative, idempotent, distributive, and • p ⊰b⊱ q = q ⊰not(b)⊱ p (skew symm) • (p ⊰b⊱ p’ ) ⊰c⊱ (q⊰b⊱ q’) = (p ⊰c⊱ q) ⊰b⊱ (p’ ⊰c⊱ q’) (exchange)

  39. Transaction • Defined as (p ⊓..b) ⊔ (q ⊓..c) • where ..b describes all executions that end satisfying single-state predicate b . • Implementation: • execute p first • test the condition b afterwards • terminate if b is true • backtrack on failure of b • and try alternative q with condition c.

  40. Transaction (realistic) • Let r describe the non-failing executions of a transaction t . • r is known when execution of t is complete. • any successful execution of t is committed • a single failed execution of t is undone, • and q is done instead. • Define: (t if r else q) = t if t ⊑ r = (t ⊓ r) ⊔ q otherwise

  41. Contracts • Let q be the body of a subroutine • Let s be its specification • Let (q .. s) assert that q meets s • Programmer error (⊤) if not so • Caller of subroutine may assume that s describes all its calls • Implementation may just execute q

  42. Least upper bound • Let S be an arbitrary set of designs • Define ⊔S as least solution of ∀s∊ S . s ⊑ _ • ( ∀s∊ S . s ⊑ r) ⇒ ⊔S ⊑ r (all r) • everything is an upper bound of { } , so ⊔ { } =  • a case where ⊔S ∉ S

  43. similarly • ⊓S is greatest lower bound of S • ⊓ { } = ⊤

  44. Subroutine with contract: q .. s • Define (q..s) as glb of the set q ⊑ _ & _ ⊑ s • Theorem: (q.. s) = q if q ⊑ s = ⊤ otherwise

  45. Iteration (Kleene *) • q* is least solution of • (ɛ ⊔ (q; _) ) ⊑ _ • q* =def⊔{s| (ɛ ⊔ q; s) ⊑ s} • ɛ ⊔ q; q* ⊑ q* • ɛ ⊔ q; q’ ⊑ q’ implies q* ⊑ q’ • q*=⊔ {qⁿ | n ∊ Nat} (continuity) • Rule (invariance): • {p}q*{p} if {p}q{p}

  46. Infinite replication • !p is the greatest solution of _ ⊑ p|_ • as in the pi calculus • all executions of !p are infinite • or possibly empty

  47. Recursion • Let F(_) be a monotonic function between programs. • Theorem: all functions defined by monotonic operators are monotonic. • μF is strongest solution of F(_) ⊑ _ • νF is weakest solution of _ ⊑ F(_) • Theorem (Knaster-Tarski): These solutions exist.

  48. Basic statements/assertions • skip  • bottom  • top ⊤ • assignment: x := e(x) • assertion: assert b • assumption: assume b • finally ..b • initially b..

  49. more • assign thru pointer: [a] := e • output: c!e • input: c?x • points to: a|-> e • a |-> _ =def exists v . a|-> v • throw, catch • alloc, dispose

  50. Laws(examples) • assume b =def b..⊓ • assert b =defb..⊓ ⊔ not(b).. • x:=e(x) ; x:=f(x) = x := f(e(x)) • in a sequential language

More Related