Commutativity and Coarse-Grained Transactions Maurice Herlihy Brown University Joint work with Eric Koskinen and Matthew Parkinson (POPL 10)

CCDP February Moore’s Law (hat tip: Herb Sutter) Clock speed flattening sharply Transistor count still rising

CCDP February The Multicore Processor cache Bus shared memory cache More processors, Same clock Sun T2000 Niagara

CCDP February What Keeps Microsoft and Intel awake at Night? If more cores does not deliver more value … Then why upgrade? ?

CCDP February Washing Machine Science? Computers could become like washing machines You don’t trade it in every 2 years for a cooler model You keep it until it breaks.

CCDP February What could possibly go wrong? Concurrent programming is hard Locks, monitors, etc. do not scale –Confusing –Subject to deadlock –Relies on conventions –Not composable –…

CCDP February The Transactional Manifesto Threads + locking don’t scale Replace locking with a transactional API Promising … but not there yet

CCDP February Challenge Do transactions provide enough concurrency? –As implemented, arguably No. Does the transactional model provide enough concurrency? –Arguably, Yes.

TMW April 2010 Skew Heaps 0 1 Tree with “heap” property 2 4 3

TMW April 2010 Concurrent Skew Heap Insert me! 6

TMW April 2010 Concurrent Skew Heap Lock parent Swap R & L

TMW April 2010 Concurrent Skew Heap Lock right child Unlock parent 2

TMW April 2010 Concurrent Skew Heap No global rebalancing Good amortized performance Good concurrency

TMW April 2010 Transactional Skew Heap Insert me! 6

TMW April 2010 Transactional Skew Heap I wrote 0 Write-write conflict! Good concurrency with locking Not with transactions … Confusion between thread-level & transaction-level synchronization Confusion between thread-level & transaction-level synchronization

TMW April 2010 Coarse-Grained Synchronization Synchronize on high-level operations, Like add(), remove(), etc. … Not low-level reads and writes Synchronize on high-level operations, Like add(), remove(), etc. … Not low-level reads and writes Pessimistic: update in place, undo on abort Optimistic: update private copy, apply changes on commit But what is the meaning of conflict?

TMW April 2010 Pessimistic Boosting transactions Abstract locks Black-box linearizable data object Undo Logs

TMW April 2010 Pessimistic Boosting transactions Abstract locks Black-box linearizable data object Undo Logs add(x)

TMW April 2010 Pessimistic Boosting transactions Abstract locks Black-box linearizable data object Undo Logs add(x)

TMW April 2010 Pessimistic Boosting transactions Abstract locks Black-box linearizable data object Undo Logs add(x)

TMW April 2010 Pessimistic Boosting transactions Abstract locks Black-box linearizable data object rem(x) Undo Logs add(x) x

TMW April 2010 Pessimistic Boosting transactions Abstract locks Black-box linearizable data object rem(x) Undo Logs add(x) x add(y) y

TMW April 2010 Pessimistic Boosting transactions Abstract locks Black-box linearizable data object rem(x) Undo Logs add(x) x member(x)

TMW April 2010 Pessimistic Boosting Thread-safe base object Updated in place Log Inverses Conflicting operations blocked by abstract locks What does it mean for operations to conflict?

TMW April 2010 Optimistic Boosting Black-box linearizable data object

TMW April 2010 Optimistic Boosting private copies Black-box linearizable data object

TMW April 2010 Optimistic Boosting redo logs private copies Black-box linearizable data object

TMW April 2010 Optimistic Boosting redo logs private copies Black-box linearizable data object add(x)

TMW April 2010 Optimistic Boosting add(x) redo logs private copies Black-box linearizable data object add(x) x

TMW April 2010 Optimistic Boosting add(x) add(y) redo logs private copies Black-box linearizable data object add(x) x add(y) y

TMW April 2010 On Commit add(x) add(y) redo logs private copies Black-box linearizable data object x y add(x)

TMW April 2010 On Commit add(x) add(y) redo logs private copies Black-box linearizable data object x y add(x) No conflict, apply updates to my copy x x

TMW April 2010 On Commit add(x) add(y) x y add(x) x x Different physical values, Same logical values

TMW April 2010 On Commit add(x) rem(x) redo logs private copies Black-box linearizable data object x add(x) Conflict! Abort & restore my copy x

TMW April 2010 Optimistic Boosting Thread-local object copies Deferred operatons kept in redo log No inverses On commit, broadcast deferred operations To other transactions, public copy On commit, broadcast deferred operations To other transactions, public copy Transactions snoop on broadcast, Abort if conflict detected Transactions snoop on broadcast, Abort if conflict detected What does it mean for operations to conflict?

TMW April 2010 Left-Movers time legal history

TMW April 2010 Left-Movers time If and are adjacent, Ok to move earlier

Left-Mover Example: Semaphore time inc()dec() 1 010

Inc() is Left-mover WRT Dec() time inc()dec()

Same sequence of calls (results unaffected) Left-Mover Example: Semaphore time inc()dec()

Same final state Left-Mover Example: Semaphore time inc()dec()

Left-Mover Counter-example time 1 dec() 0 inc() 1 dec() 0

Dec() not Left-Mover WRT Inc() time 1 dec() 0 inc() 1 dec() 0

Right-Movers time legal history

Right-Movers time If and are adjacent, Ok to move later

Commutativity time If and are adjacent, Ok to swap

47 Pessimistic Semantics (modify shared state in place) time Txn B beg Txn A beg Pessimistic Commit: Move Left of pending cmt

48 Pessimistic Semantics (modify shared state in place) time Txn B beg Txn A beg abt

49 Pessimistic Semantics (modify shared state in place) time 3 Txn B beg Txn A beg Pessimistic Abort: Move Right of pending Pessimistic Abort: Pending ops move Left

50 Optimistic Semantics (modify local copies; merge) time Txn B Txn A beg Optimistic Commit: Move Right of committed cmt

51 Optimistic Semantics (modify local copies; merge) time Txn B Txn A beg Optimistic Abort: Discard Operations abt cmt

PessimisticOptimistic Two Execution Models 52 Left-MovernessRight-Moverness Algebraic Abstract Properties

53 But … Are commutativity+inverses the limit? –Other algebraic properties? Abstract locks are blocking –may cause multiple transactions –may block on same lock

54 Example atomic { with (abstractLock(3)){ if (skiplist.insert(3)) { self.onAbort.add( (λ() skiplist.remove(3))) } bigComputation(); } Lock key 3

55 Example atomic { with (abstractLock(3)){ if (skiplist.insert(3)) { self.onAbort.add( (λ() skiplist.remove(3))) } bigComputation(); } Add value 3

56 Example atomic { with (abstractLock(3)){ if (skiplist.insert(3)) { self.onAbort.add( (λ() skiplist.remove(3))) } bigComputation(); } If set modified, Log inverse

57 Example atomic { with (abstractLock(3)){ if (skiplist.insert(3)) { self.onAbort.add( (λ() skiplist.remove(3))) } bigComputation(); } Do something long, Not involving skiplist

58 Conflicting Operations remove(3) insert(3) no conflict

59 Conflicting Locks remove(3) insert(3) (3) No concurrency

60 Conflicting Locks insert(3) (3) remove(3) (3)

61 Conflicting Locks insert(3) (3) remove(3) (3)

62 Conflicting Locks insert(3) (3) remove(3) (3) Lock handoff

63 Lock Handoff dependence

64 Lock Handoff dependence Lock handoff

65 Key Ideas Handing off Abstract lock Allows concurrent non-commuting boosted transactions! Novel ideas –Mechanism for passing abstract lock –Thread-local cyclic dependency check –Lazy recovery

66 Deadlock?

67 Detection Dreadlocks –[Herlihy & Koskinen, SPAA 2008] Fast, incremental deadlock detection Low overhead Cache-friendly

68 Waits-For Graph waiting owned

69 Digest

70 Digest

71 Digest Uh-oh!

72 Details Can represent digest as –Bit map (small population) –Bloom filter (larger population) [Herlihy & Koskinen, SPAA 2008]

Challenges Automation? –Theorem proving –Model checking Compiler & Language support? Implementation …