Extending Trace Models

Tony HoareIan Wehrman

Traces

• Trace: set of events + dependency relation– an execution of a program

tr

Trace Separation

• Weak separation (*)• tp * tq = tp U tq when tp tq =

• Sequential separation (;)– tp ; tq = tp * tq when not tp ← tp

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

Reasoning About Traces

• Theorem: (P ; Q) ; R = P ; (Q ; R)1. Show (tp ; tq) ; tr = tp ; (tq ; tr) for traces tp,tq,tr

(tp ; tq) ; tr= { def of (;) }

(tp ; tq) U tr if not (tp ; tq) ← tr= { def of (;) }

tp U tq U tr if not tp ← tq, tp ← tr, tq ← tr= { symmetric }

tp ; (tq ; tr)

2. Lift from traces to trace sets

Limitations of Traces

• Trace reasoning requires program implementation

• Too detailed for design phase• More abstract model needed

Interfaces

• Execution of P represented by its interface• An interface ip is 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 (;’)

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

From Traces to Interfaces

αin(tr) αout(tr)

tr

• Models related by abstraction function– α = <αin, αout>

From Traces to Interfaces

– αin(tr) = { a | a’ tr & ¬(a0 tr) }

– αout(tr) = { a | a0 tr & ¬(a’ tr) }

αin(tr) αout(tr)

tr

Interface Separation

ip

iq

ip *’ iq

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) =

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)

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))

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

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 := x3

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 (;”)

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

Valuation Separation

vp

vq

vp *” vq

3

1 9

8

5

4

From Interfaces to Valuations

• Models are related by the global valuation function : AR → VAL

in(ip) out(ip)

ip3

4 8

↑ in(ip) ↑ out(ip)

↑ ip

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.

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

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

Questions?

Valuations

in(tr) out(tr)

tr

Trace Picture

Relating the Separators

• Abstraction preserves separation: – α(tp * tq) = α(tp) *’ α(tq)

ip

iq

Relating the Models

• Homomorphisms: – traces → interfaces– trace sets → interface sets

• Consequences:– reason about programs without implementation– trace algebra equations still true

Program Algebra

• Trace sets model program algebra– Operations defined on traces– Lifted pointwise to sets of traces

• Ex: weak separator (*)– tr = tp * tq iff tr = tp U tq and tp tq = – R = P * Q iff trR tp P, tqQ. tr = tp * tq

• Ex: sequential separator (;)– tr = tp ; tq iff tr = tp * tq and not tp ← tp

Interface Picture

In Out