 Download Presentation Algebra of Concurrent Programming # Algebra of Concurrent Programming - PowerPoint PPT Presentation

Download Presentation ##### Algebra of Concurrent Programming

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. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.

- - - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - - -
##### Presentation Transcript

1. Algebra of Concurrent Programming Tony Hoare Redmond August 2011

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 terminologyp ⊑ 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’;q’ if p ⊑ p’ • p;q⊑ p’;q’ if q ⊑ q’ • compare: addition of numbers • Theorem (rule of consequence): • p’ ⊑ p & {p} q {r} & r ⊑ r’ implies {p’} q {r’} • Theorem implies first law

14. associativity • Law (; is associative) : • (p;q);q’ = p;(q;q’) • Theorem (sequential composition): • {p} q {s} & {s} q’ {r} implies{p} q;q’ {r} • half the law provable from theorem

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

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. • 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) • Theorem (frame rule) : • {p} q {r} implies {p|s} q {r|s} • Theorem implies left locality

18. Concurrency law • Law (; exchanges with *) • (p|q) ; (p’|q’) ⊑ (p;p’) | (q;q’) • like exchange law of category theory • Theorem (| compositional) • {p} q {r} & {p’} q’ {r’} implies {p|p’} q|q’ {r|r’} • Theorem implies the 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) to combine 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 • there is no point in executing it

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 • Theorem (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 provable from theorem

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 an alternative q with condition c.

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

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

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. 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) • Theorem (invariance): • {p}q*{p} if {p}q{p}

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

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

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

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