136 Views

Download Presentation
##### 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. 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 - - - - - - - - - - - - - - - - - - - - - - - - - - -

**Algebra of Concurrent Programming**Tony Hoare Redmond August 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**• 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.**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**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**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**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**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)**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**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**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**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 .**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**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**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**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**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**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**p|q;p’|q’**p p’ q q’ by columns**p|q;p’|q’**⊑ p p’ p;p’ |q;q’ q q’ by rows**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”)**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**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’**Conclusion**• regular expressions satisfy all our laws for ⊑ , ; , and | • and for other operators introduced later**Part 2. More Program Control Structures**• Non-determinism, intersection • Iteration, recursion, fixed points • Subroutines, contracts, transactions • Basic commands**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.**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**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**programs include**• sequential composition (;) • concurrent composition (|) • interrupts • iteration, recursion • contracts (declarations) • transactions • assignments, inputs, outputs, jumps,… • So include these in our specifications!**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)**Algebra of **• Law ( is the zero of ;) : • ; p = = p ; • Theorem : {p} {q} • Quarter of law provable from theorem**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: _ ⊑ _**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 ⊤**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**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 ⊤**glb (meet): ⊓**• Define p⊓qas greatest solution of _ ⊑ p & _ ⊑ q**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**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)**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.**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**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**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**similarly**• ⊓S is greatest lower bound of S • ⊓ { } = ⊤**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}**Infinite replication**• !p is the greatest solution of _ ⊑ p|_ • as in the pi calculus • all executions of !p are infinite • or possibly empty**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.**Subroutine with contract: q .. s**• Define (q..s) as glb of the set q ⊑ _ & _ ⊑ s • Theorem: (q.. s) = q if q ⊑ s = ⊤ otherwise**Basic statements/assertions**• skip • bottom • top ⊤ • assignment: x := e(x) • assertion: assert b • assumption: assume b • finally ..b • initially b..**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**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