Extending Trace Models

1. Extending Trace Models Tony Hoare Ian Wehrman

2. Traces • Trace: set of events + dependency relation • an execution of a program tr

3. Trace Separation • Weak separation (*) • tp * tq=tp U tqwhen tptq =  • Sequential separation (;) • tp ; tq= tp * tqwhen nottp ← tp

4. Trace Semantics • Trace algebra: • Traces + separators • Complex trace algebra • Sets of traces + separators lifted point-wise • P * Q = { tp * tq | tp P, tqQ } • Meaning of P: the set of traces that result from execution of P

5. Reasoning About Traces • Theorem: (P ; Q) ; R = P ; (Q ; R) • Show (tp ; tq) ; tr = tp ; (tq ; tr) for traces tp,tq,tr (tp ; tq) ; tr • { def of (;) } (tp ; tq) Utrif not (tp ; tq) ← tr • { def of (;) } tp U tq U trif not tp ← tq, tp ← tr, tq ← tr • { symmetric } tp ; (tq ; tr) • Lift from traces to trace sets

6. Limitations of Traces • Trace reasoning requires program implementation • Too detailed for design phase • More abstract model needed

7. Interfaces • Execution of P represented by its interface • An interface ipis two sets of arrows: • in(ip): what the execution requires • out(ip): what the execution provides • Define (later) analogous interface operations • weak interface separation (*’) • sequential interface separation (;’)

8. Interface Semantics • Interface algebra: • interfaces + separators • Complex interface algebra: • sets of interfaces + pointwise-lifted separators • P *’ Q = { ip *’ iq | ip P, iq Q } • Meaning of P: the set of interfaces that result from execution of P

9. From Traces to Interfaces • Models related by abstraction function • α = <αin, αout> tr αin(tr) αout(tr)

10. From Traces to Interfaces • αin(tr) = { a | a’  tr & ¬(a0  tr) } • αout(tr) = { a | a0 tr & ¬(a’  tr) } tr αin(tr) αout(tr)

11. Interface Separation ip ip *’ iq iq

12. Interface Separation • Def. of interface separation (pair of sets): • in(ip *’ iq) = in(ip)\out(iq) U in(iq)\out(iq) • if in(ip)  in(iq) =  • out(ip *’ iq) = out(ip)\in(iq) U out(iq)\in(ip) • if out(ip)  out(iq) = 

13. Relating the Models • Abstraction function α is a homomorphism: • trace alg. → interface alg. • α(tp * tq) = α(tp) *’ α(tq) • Lifted function Pα is a homomorphism: • complex trace alg. → complex interface alg. • Pα(P * Q) = Pα(P) *’ Pα(Q)

14. Lifting Lemma • Write F,G,H for pointwise-lifted funs f,g,h • Lemma: H(F(A,B)) • { def of H } { h(x) | x  F(A,B) } • { def of F } { h(f(a,b)) | a  A, B  B } • { homomorphism assumption: h(f(a,b)) = g(h(a),h(b)) } { g(h(a),h(b)) | a  A, B  B } • { def of H } { g(x,y) | x  H(A), y  H(B)} • { def of G } G(H(A),H(B))

15. Consequences • Interfaces are a more abstract program model • Homomorphism from traces shows previous identities still hold • Program features handled modularly • No induction on program structure

16. Next step: Dataflow • Dependencies indicate data transfer • Variables: x := 3; y := x • Channels: x<3>.P | x(y).Q • New model: arrows (at interface) carry values x := 3 y := x 3

17. Valuations • A valuation vp is two partial functions: • in(vp): values the execution requires • out(vp): values the execution provides • Consistency requirement: • in(vp), out(vp)  , for some total  : AR → VAL • Define (later) valuation operations • weak valuation separation (*”) • sequential valuation separation (;”)

18. Valuation Semantics • Valuation algebra: • interfaces + separators • Complex valuation algebra: • sets of valuations + pointwise-lifted separators • P *” Q = { vp *” vq | vp P, vq Q } • Meaning of P: the set of valuations that consistent with execution of P

19. Valuation Separation vp 3 8 4 vp *” vq 5 vq 1 9

20. From Interfaces to Valuations • Models are related by the global valuation function  : AR → VAL  ↑ ip ip 3 4 8  ↑ in(ip) in(ip)  ↑ out(ip) out(ip)

21. From Interfaces to Valuations • Models are related by the global valuation function  : AR → VAL • Restriction of  gives a homomorphism: • interface alg → valuation alg. •  ↑ (ip *’ iq) = ( ↑ ip) *” ( ↑ iq) • Use lifting lemma again to show homomorphism: • complex interface alg.→complex valuation alg.

22. Consequences • Valuations are more abstract, but carry information about dataflow • Homomorphism from interfaces (and traces) shows previous identities still hold • Program features still handled modularly • Repeat process to abstract or enrich model further

23. Next Steps • Label arrows with location-value pairs • For modeling multiple-assignment vars, heaps • Healthiness conditions distinguish memory models • Also want to model control dependencies • Current model can’t describe if-then-else

24. Questions?

27. Valuations tr in(tr) out(tr)

28. Trace Picture

29. Relating the Separators • Abstraction preserves separation: • α(tp * tq) = α(tp) *’ α(tq) ip iq

30. Relating the Models • Homomorphisms: • traces → interfaces • trace sets → interface sets • Consequences: • reason about programs without implementation • trace algebra equations still true

31. Program Algebra • Trace sets model program algebra • Operations defined on traces • Lifted pointwise to sets of traces • Ex: weak separator (*) • tr = tp * tqifftr = tp U tqand tptq =  • R = P * Q ifftrR tp P, tqQ. tr = tp * tq • Ex: sequential separator (;) • tr = tp ; tqifftr = tp * tqand nottp ← tp

32. Interface Picture In Out