Implementing Atomicity with Locks Dave Cunningham April 4, 2006 - - PowerPoint PPT Presentation

Outline Motivation Analysis Of Accessed Objects Conclusion

Implementing Atomicity with Locks

Dave Cunningham April 4, 2006

Dave Cunningham Implementing Atomicity with Locks 1/16

Outline Motivation Analysis Of Accessed Objects Conclusion

Motivation The Problem A New Solution Example Analysis Of Accessed Objects Examples Formalism Correctness Termination Conclusion Conclusion Future work

Dave Cunningham Implementing Atomicity with Locks 2/16

Outline Motivation Analysis Of Accessed Objects Conclusion The Problem A New Solution Example

Atomic Section

Future concurrent programming languages may include the atomic section.

atomic { account.balance := account.balance - amount; log.append("withdrew ..."); }

Dave Cunningham Implementing Atomicity with Locks 3/16

Outline Motivation Analysis Of Accessed Objects Conclusion The Problem A New Solution Example

Atomic Section

Future concurrent programming languages may include the atomic section.

atomic { account.balance := account.balance - amount; log.append("withdrew ..."); }

◮ Efficient implementations must understand interference.

Dave Cunningham Implementing Atomicity with Locks 3/16

Outline Motivation Analysis Of Accessed Objects Conclusion The Problem A New Solution Example

Atomic Section

Future concurrent programming languages may include the atomic section.

atomic { account.balance := account.balance - amount; log.append("withdrew ..."); }

◮ Efficient implementations must understand interference. ◮ What objects are accessed by atomic code?

Dave Cunningham Implementing Atomicity with Locks 3/16

Outline Motivation Analysis Of Accessed Objects Conclusion The Problem A New Solution Example

Two Approaches

Transactions: Log object accesses at runtime.

◮ Concurrent logs with non-empty intersection ⇒ interference. ◮ Interference avoided by undoing (or not committing) code. ◮ Atomic code re-executed.

Dave Cunningham Implementing Atomicity with Locks 4/16

Outline Motivation Analysis Of Accessed Objects Conclusion The Problem A New Solution Example

Two Approaches

Transactions: Log object accesses at runtime.

◮ Concurrent logs with non-empty intersection ⇒ interference. ◮ Interference avoided by undoing (or not committing) code. ◮ Atomic code re-executed.

Alternative: Statically infer what objects may be accessed

◮ Prevent interference using synchronisation. ◮ Dataflow analysis may be inaccurate (arbitrary pointers). ◮ But programmers already do this in their heads. . .

Dave Cunningham Implementing Atomicity with Locks 4/16

Outline Motivation Analysis Of Accessed Objects Conclusion The Problem A New Solution Example

Two Approaches

Transactions: Log object accesses at runtime.

◮ Concurrent logs with non-empty intersection ⇒ interference. ◮ Interference avoided by undoing (or not committing) code. ◮ Atomic code re-executed.

Alternative: Statically infer what objects may be accessed

◮ Prevent interference using synchronisation. ◮ Dataflow analysis may be inaccurate (arbitrary pointers). ◮ But programmers already do this in their heads. . .

(Like Ethernet vs Token Ring)

Dave Cunningham Implementing Atomicity with Locks 4/16

Outline Motivation Analysis Of Accessed Objects Conclusion The Problem A New Solution Example

Interference Prevention

account.balance := account.balance - amount; log.append("withdrew ...");

Dave Cunningham Implementing Atomicity with Locks 5/16

Outline Motivation Analysis Of Accessed Objects Conclusion The Problem A New Solution Example

Interference Prevention

synchronized (account,log) { account.balance := account.balance - amount; log.append("withdrew ..."); }

Dave Cunningham Implementing Atomicity with Locks 5/16

Outline Motivation Analysis Of Accessed Objects Conclusion The Problem A New Solution Example

Interference Prevention

synchronized (account,log) { account.balance := account.balance - amount; log.append("withdrew ..."); }

Static Inference returns {account, log} Dynamic Evaluate {account, log} to find out what to lock.

Dave Cunningham Implementing Atomicity with Locks 5/16

Outline Motivation Analysis Of Accessed Objects Conclusion The Problem A New Solution Example

Interference Prevention

synchronized (account,log) { account.balance := account.balance - amount; log.append("withdrew ..."); }

Static Inference returns {account, log} Dynamic Evaluate {account, log} to find out what to lock. What should the analysis return in general?

Dave Cunningham Implementing Atomicity with Locks 5/16

Outline Motivation Analysis Of Accessed Objects Conclusion The Problem A New Solution Example

Interference Prevention

synchronized (account,log) { account.balance := account.balance - amount; log.append("withdrew ..."); }

Static Inference returns {account, log} Dynamic Evaluate {account, log} to find out what to lock. What should the analysis return in general?

◮ Variables?

Dave Cunningham Implementing Atomicity with Locks 5/16

Outline Motivation Analysis Of Accessed Objects Conclusion The Problem A New Solution Example

Interference Prevention

synchronized (account,log) { account.balance := account.balance - amount; log.append("withdrew ..."); }

Static Inference returns {account, log} Dynamic Evaluate {account, log} to find out what to lock. What should the analysis return in general?

◮ Variables? ◮ Arbitrary expressions?

Dave Cunningham Implementing Atomicity with Locks 5/16

Outline Motivation Analysis Of Accessed Objects Conclusion The Problem A New Solution Example

Interference Prevention

synchronized (account,log) { account.balance := account.balance - amount; log.append("withdrew ..."); }

Static Inference returns {account, log} Dynamic Evaluate {account, log} to find out what to lock. What should the analysis return in general?

◮ Variables? ◮ Arbitrary expressions?

Paths: sequences of field lookups:

◮ me.brother.girlfriend.car ◮ list.first.next.next.next

Dave Cunningham Implementing Atomicity with Locks 5/16

Outline Motivation Analysis Of Accessed Objects Conclusion Examples Formalism Correctness Termination

Examples (1)

e L(e) me.brother.car.fuel := 100; { me, me.brother, me.brother.car } if (goodWeather) { this.clothing := drawer.hat; } else { this.clothing := cloakroom.umbrella; } { this, drawer, cloakroom }

Dave Cunningham Implementing Atomicity with Locks 6/16

Outline Motivation Analysis Of Accessed Objects Conclusion Examples Formalism Correctness Termination

Examples (2)

e L(e) me.car := you.car; me.car.fuel := 100; { me, you, you.car } me.car := you.car; dave.car.fuel := 100; { me, you, you.car, dave, dave.car }

Dave Cunningham Implementing Atomicity with Locks 7/16

Outline Motivation Analysis Of Accessed Objects Conclusion Examples Formalism Correctness Termination

Definition of L

Intuition: L(e) ≈ “objects that may be accessed by e”

Dave Cunningham Implementing Atomicity with Locks 8/16

Outline Motivation Analysis Of Accessed Objects Conclusion Examples Formalism Correctness Termination

Definition of L

Intuition: L(e) ≈ “objects that may be accessed by e” (in terms of paths through the initial heap)

Dave Cunningham Implementing Atomicity with Locks 8/16

Outline Motivation Analysis Of Accessed Objects Conclusion Examples Formalism Correctness Termination

Definition of L

Intuition: L(e) ≈ “objects that may be accessed by e” (in terms of paths through the initial heap) Definition: L(x) = ∅

Dave Cunningham Implementing Atomicity with Locks 8/16

Outline Motivation Analysis Of Accessed Objects Conclusion Examples Formalism Correctness Termination

Definition of L

Intuition: L(e) ≈ “objects that may be accessed by e” (in terms of paths through the initial heap) Definition: L(x) = ∅ L(if q e1 e2) = L(q) ∪ (L(e1) ∪ L(e2))

Dave Cunningham Implementing Atomicity with Locks 8/16

Outline Motivation Analysis Of Accessed Objects Conclusion Examples Formalism Correctness Termination

Definition of L

Intuition: L(e) ≈ “objects that may be accessed by e” (in terms of paths through the initial heap) Definition: L(x) = ∅ L(if q e1 e2) = L(q) ∪ (L(e1) ∪ L(e2)) L(q.f ) = L(q) ∪ {q} L(q.f := r) = L(q) ∪ L(r) ∪ {q}

Dave Cunningham Implementing Atomicity with Locks 8/16

Outline Motivation Analysis Of Accessed Objects Conclusion Examples Formalism Correctness Termination

Definition of L

Intuition: L(e) ≈ “objects that may be accessed by e” (in terms of paths through the initial heap) Definition: L(x) = ∅ L(if q e1 e2) = L(q) ∪ (L(e1) ∪ L(e2)) L(q.f ) = L(q) ∪ {q} L(q.f := r) = L(q) ∪ L(r) ∪ {q} L(e1; e2) = L(e1) ∪ Te1(L(e2))

Dave Cunningham Implementing Atomicity with Locks 8/16

Outline Motivation Analysis Of Accessed Objects Conclusion Examples Formalism Correctness Termination

Definition of T

Intuition: Te(P′) ≈ “P′ translated with respect to the side-effects of e”

Dave Cunningham Implementing Atomicity with Locks 9/16

Outline Motivation Analysis Of Accessed Objects Conclusion Examples Formalism Correctness Termination

Definition of T

Intuition: Te(P′) ≈ “P′ translated with respect to the side-effects of e” Definition: Tx(P′) = P′ Tq.f (P′) = P′

Dave Cunningham Implementing Atomicity with Locks 9/16

Outline Motivation Analysis Of Accessed Objects Conclusion Examples Formalism Correctness Termination

Definition of T

Intuition: Te(P′) ≈ “P′ translated with respect to the side-effects of e” Definition: Tx(P′) = P′ Tq.f (P′) = P′ Tif q e1 e2(P′) = Te1(P′) ∪ Te2(P′) Te1;e2(P′) = Te1(Te2(P′))

Dave Cunningham Implementing Atomicity with Locks 9/16

Outline Motivation Analysis Of Accessed Objects Conclusion Examples Formalism Correctness Termination

Definition of T

Intuition: Te(P′) ≈ “P′ translated with respect to the side-effects of e” Definition: Tx(P′) = P′ Tq.f (P′) = P′ Tif q e1 e2(P′) = Te1(P′) ∪ Te2(P′) Te1;e2(P′) = Te1(Te2(P′)) Tq.f :=r(P′) = something horrible...

Dave Cunningham Implementing Atomicity with Locks 9/16

Outline Motivation Analysis Of Accessed Objects Conclusion Examples Formalism Correctness Termination

Definition of T

Intuition: Te(P′) ≈ “P′ translated with respect to the side-effects of e” Definition: Tx(P′) = P′ Tq.f (P′) = P′ Tif q e1 e2(P′) = Te1(P′) ∪ Te2(P′) Te1;e2(P′) = Te1(Te2(P′)) Tq.f :=r(P′) = something horrible...

• p′∈P′
• { r.g | p′ = .f .g }

∪ ∅ if p′ = q.f . . . {p′}

• therwise
• Dave Cunningham

Implementing Atomicity with Locks 9/16

Outline Motivation Analysis Of Accessed Objects Conclusion Examples Formalism Correctness Termination

While loops

Infer a set of constraints and propogate solutions until fixed point. L(while p e) ⊇ L(p; e) ∪ TeL(while p e) Twhile p e(P′) ⊇ P′ ∪ Te(Twhile p e(P′))

Dave Cunningham Implementing Atomicity with Locks 10/16

Outline Motivation Analysis Of Accessed Objects Conclusion Examples Formalism Correctness Termination

Correctness

Can we prove that L(e) always returns the right results?

Dave Cunningham Implementing Atomicity with Locks 11/16

Outline Motivation Analysis Of Accessed Objects Conclusion Examples Formalism Correctness Termination

Correctness

Can we prove that L(e) always returns the right results?

◮ Define operational semantics. e, h A

v, h′

Dave Cunningham Implementing Atomicity with Locks 11/16

Outline Motivation Analysis Of Accessed Objects Conclusion Examples Formalism Correctness Termination

Correctness

Can we prove that L(e) always returns the right results?

◮ Define operational semantics. e, h A

v, h′

◮ Define correctness property for L, T.

Dave Cunningham Implementing Atomicity with Locks 11/16

Outline Motivation Analysis Of Accessed Objects Conclusion Examples Formalism Correctness Termination

Correctness

Can we prove that L(e) always returns the right results?

◮ Define operational semantics. e, h A

v, h′

◮ Define correctness property for L, T.

A ⊆ { h(p) | p ∈ L(e) }

Dave Cunningham Implementing Atomicity with Locks 11/16

Outline Motivation Analysis Of Accessed Objects Conclusion Examples Formalism Correctness Termination

Correctness

Can we prove that L(e) always returns the right results?

◮ Define operational semantics. e, h A

v, h′

◮ Define correctness property for L, T.

A ⊆ { h(p) | p ∈ L(e) } ∀P′ . { h′(p′) | p′ ∈ P′ } ⊆ { h(p) | p ∈ Te(P′) }

Dave Cunningham Implementing Atomicity with Locks 11/16

Outline Motivation Analysis Of Accessed Objects Conclusion Examples Formalism Correctness Termination

Correctness

Can we prove that L(e) always returns the right results?

◮ Define operational semantics. e, h A

v, h′

◮ Define correctness property for L, T.

A ⊆ { h(p) | p ∈ L(e) } ∀P′ . { h′(p′) | p′ ∈ P′ } ⊆ { h(p) | p ∈ Te(P′) }

◮ Prove by induction over structure of execution.

Dave Cunningham Implementing Atomicity with Locks 11/16

Outline Motivation Analysis Of Accessed Objects Conclusion Examples Formalism Correctness Termination

Termination

Can we prove that the analysis finishes in finite time?

Dave Cunningham Implementing Atomicity with Locks 12/16

Outline Motivation Analysis Of Accessed Objects Conclusion Examples Formalism Correctness Termination

Termination

Can we prove that the analysis finishes in finite time?

e L(e) atomic { while (x.next) x := x.next; }

Dave Cunningham Implementing Atomicity with Locks 12/16

Outline Motivation Analysis Of Accessed Objects Conclusion Examples Formalism Correctness Termination

Termination

Can we prove that the analysis finishes in finite time?

e L(e) atomic { while (x.next) x := x.next; } { x,

Dave Cunningham Implementing Atomicity with Locks 12/16

Outline Motivation Analysis Of Accessed Objects Conclusion Examples Formalism Correctness Termination

Termination

Can we prove that the analysis finishes in finite time?

e L(e) atomic { while (x.next) x := x.next; } { x, x.next,

Dave Cunningham Implementing Atomicity with Locks 12/16

Outline Motivation Analysis Of Accessed Objects Conclusion Examples Formalism Correctness Termination

Termination

Can we prove that the analysis finishes in finite time?

e L(e) atomic { while (x.next) x := x.next; } { x, x.next, x.next.next,

Dave Cunningham Implementing Atomicity with Locks 12/16

Outline Motivation Analysis Of Accessed Objects Conclusion Examples Formalism Correctness Termination

Termination

Can we prove that the analysis finishes in finite time?

e L(e) atomic { while (x.next) x := x.next; } { x, x.next, x.next.next, x.next.next.next,

Dave Cunningham Implementing Atomicity with Locks 12/16

Outline Motivation Analysis Of Accessed Objects Conclusion Examples Formalism Correctness Termination

Termination

Can we prove that the analysis finishes in finite time?

e L(e) atomic { while (x.next) x := x.next; } { x, x.next, x.next.next, x.next.next.next, . . . }

Dave Cunningham Implementing Atomicity with Locks 12/16

Outline Motivation Analysis Of Accessed Objects Conclusion Examples Formalism Correctness Termination

Termination

Can we prove that the analysis finishes in finite time?

e L(e) atomic { while (x.next) x := x.next; } { x, x.next, x.next.next, x.next.next.next, . . . }

L(e) ⊇ {x} ∪ { p.next | p ∈ L(e) }

Dave Cunningham Implementing Atomicity with Locks 12/16

Outline Motivation Analysis Of Accessed Objects Conclusion Examples Formalism Correctness Termination

Termination

Can we prove that the analysis finishes in finite time?

e L(e) atomic { while (x.next) x := x.next; } { x, x.next, x.next.next, x.next.next.next, . . . }

L(e) ⊇ {x} ∪ { p.next | p ∈ L(e) } (No fixed point.)

Dave Cunningham Implementing Atomicity with Locks 12/16

Outline Motivation Analysis Of Accessed Objects Conclusion Conclusion Future work

Conclusion

We can implement atomic without transactions:

Dave Cunningham Implementing Atomicity with Locks 13/16

Outline Motivation Analysis Of Accessed Objects Conclusion Conclusion Future work

Conclusion

We can implement atomic without transactions:

◮ atomic {e}

Dave Cunningham Implementing Atomicity with Locks 13/16

Outline Motivation Analysis Of Accessed Objects Conclusion Conclusion Future work

Conclusion

We can implement atomic without transactions:

◮ atomic {e} −

→

Dave Cunningham Implementing Atomicity with Locks 13/16

Outline Motivation Analysis Of Accessed Objects Conclusion Conclusion Future work

Conclusion

We can implement atomic without transactions:

◮ atomic {e} −

→ synchronized (L(e)){e}

Dave Cunningham Implementing Atomicity with Locks 13/16

Outline Motivation Analysis Of Accessed Objects Conclusion Conclusion Future work

Conclusion

We can implement atomic without transactions:

◮ atomic {e} −

→ synchronized (L(e)){e}

◮ (As long as e does not use any syntax not considered here.)

Dave Cunningham Implementing Atomicity with Locks 13/16

Outline Motivation Analysis Of Accessed Objects Conclusion Conclusion Future work

Conclusion

We can implement atomic without transactions:

◮ atomic {e} −

→ synchronized (L(e)){e}

◮ (As long as e does not use any syntax not considered here.) ◮ (Assuming a suitable widening to deal with non-termination.)

Dave Cunningham Implementing Atomicity with Locks 13/16

Outline Motivation Analysis Of Accessed Objects Conclusion Conclusion Future work

Future Work

Widening of while loops.

◮ Suppose L(e) grows by field next.

Dave Cunningham Implementing Atomicity with Locks 14/16

Outline Motivation Analysis Of Accessed Objects Conclusion Conclusion Future work

Future Work

Widening of while loops.

◮ Suppose L(e) grows by field next. ◮ If type of next is C, then lock all instances of C.

Dave Cunningham Implementing Atomicity with Locks 14/16

Outline Motivation Analysis Of Accessed Objects Conclusion Conclusion Future work

Future Work

Widening of while loops.

◮ Suppose L(e) grows by field next. ◮ If type of next is C, then lock all instances of C. ◮ If next is owned by o, then lock all objects owned by o. ◮ (Programmers implicitly do this in Java.)

Dave Cunningham Implementing Atomicity with Locks 14/16

Outline Motivation Analysis Of Accessed Objects Conclusion Conclusion Future work

Future Work

Widening of while loops.

◮ Suppose L(e) grows by field next. ◮ If type of next is C, then lock all instances of C. ◮ If next is owned by o, then lock all objects owned by o. ◮ (Programmers implicitly do this in Java.)

Potential for aliasing makes analysis inaccurate.

◮ L(e) too big.

Dave Cunningham Implementing Atomicity with Locks 14/16

Outline Motivation Analysis Of Accessed Objects Conclusion Conclusion Future work

Future Work

Widening of while loops.

◮ Suppose L(e) grows by field next. ◮ If type of next is C, then lock all instances of C. ◮ If next is owned by o, then lock all objects owned by o. ◮ (Programmers implicitly do this in Java.)

Potential for aliasing makes analysis inaccurate.

◮ L(e) too big. ◮ Runtime test for aliasing before atomic section.

Dave Cunningham Implementing Atomicity with Locks 14/16

Outline Motivation Analysis Of Accessed Objects Conclusion Conclusion Future work

Future Work

Widening of while loops.

◮ Suppose L(e) grows by field next. ◮ If type of next is C, then lock all instances of C. ◮ If next is owned by o, then lock all objects owned by o. ◮ (Programmers implicitly do this in Java.)

Potential for aliasing makes analysis inaccurate.

◮ L(e) too big. ◮ Runtime test for aliasing before atomic section. ◮ Use ownership types to restrict aliasing.

Dave Cunningham Implementing Atomicity with Locks 14/16

Outline Motivation Analysis Of Accessed Objects Conclusion Conclusion Future work

Future Work

Widening of while loops.

◮ Suppose L(e) grows by field next. ◮ If type of next is C, then lock all instances of C. ◮ If next is owned by o, then lock all objects owned by o. ◮ (Programmers implicitly do this in Java.)

Potential for aliasing makes analysis inaccurate.

◮ L(e) too big. ◮ Runtime test for aliasing before atomic section. ◮ Use ownership types to restrict aliasing.

More concrete languages.

◮ Recursive methods with dynamic binding. ◮ Inheritance, exceptions, object construction, arrays, . . .

Dave Cunningham Implementing Atomicity with Locks 14/16

Outline Motivation Analysis Of Accessed Objects Conclusion Conclusion Future work

Related Work

Cormac Flanagan et al

◮ Type systems (uses ownership-esque parameters) ◮ Programs have both atomic and locking primitives ◮ The latter is verified against the former.

Dave Cunningham Implementing Atomicity with Locks 15/16

Outline Motivation Analysis Of Accessed Objects Conclusion Conclusion Future work

Related Work

Cormac Flanagan et al

◮ Type systems (uses ownership-esque parameters) ◮ Programs have both atomic and locking primitives ◮ The latter is verified against the former.

Mandana Vaziri, Frank Tip, Julian Dolby

◮ “Atomic sets” (subdivision of an object’s fields) ◮ All methods are atomic ◮ Dataflow analysis to infer the atomic sets (objects) accessed.

Dave Cunningham Implementing Atomicity with Locks 15/16

Outline Motivation Analysis Of Accessed Objects Conclusion Conclusion Future work

Related Work

Cormac Flanagan et al

◮ Type systems (uses ownership-esque parameters) ◮ Programs have both atomic and locking primitives ◮ The latter is verified against the former.

Mandana Vaziri, Frank Tip, Julian Dolby

◮ “Atomic sets” (subdivision of an object’s fields) ◮ All methods are atomic ◮ Dataflow analysis to infer the atomic sets (objects) accessed.

Both parties have formalised atomicity. Cormac uses “reduction” (Lipton’75), Vaziri uses serializability (from databases).

Dave Cunningham Implementing Atomicity with Locks 15/16

Outline Motivation Analysis Of Accessed Objects Conclusion Conclusion Future work

Emergency Slide!

Instead of: synchronized (L(e)) { e } We actually need: start: let x1 . . . xn = L(e) in synchronized (x1 . . . xn) { if (x1 . . . xn != L(e)) goto start; e }

Dave Cunningham Implementing Atomicity with Locks 16/16