Good Programming in Transactional Memory Game Theory Meets

Good Programming in Transactional Memory Game Theory Meets Multicore Architecture Raphael Eidenbenz Roger Wattenhofer

Moore‘s Law Transistor count still rising Clock speed flattening sharply Advent of multi-core processors! Raphael Eidenbenz, ETH Zurich. ISAAC 2009

Multicore Architecture § Explicit locking Transactional Memory Parallel threads Communication through shared memory Developer: Explicit locking of shared resources Mark critical sections System: Guarantee exclusive execution Raphael Eidenbenz, ETH Zurich. ISAAC 2009

Contention Management Raphael Eidenbenz, ETH Zurich. ISAAC 2009 Which transaction shall I abort? ?

Contention Managers § Timestamp Oldest transaction wins § Polite Exponential backoff priority based § Karma Transaction with most locked resources wins Priority is carried over to next attempt when aborted § Polka Karma with exponential backoff § Randomized non-priority based Pick a random winner Raphael Eidenbenz, ETH Zurich. ISAAC 2009

Is it a Game? § Yes Players = programmers Strategy space = placing of transactions Their goal: fast execution Social goal: maximize system throughput „My thread is the fastest!“ Raphael Eidenbenz, ETH Zurich. ISAAC 2009

Desired Behavior inc. Ring. Counters. GP(Node start){ var cur = start; while(cur. next!=start){ transaction{cur. do. Something(); } cur = cur. next; }} inc. Ring. Counters(Node start){ var cur = start; transaction{ while(cur. next!=start){ cur. do. Something(); cur = cur. next; } }} R 1 R 2 R 3 Rs Rs t Ø Transactions as short as possible! Raphael Eidenbenz, ETH Zurich. ISAAC 2009 t

Simulation Setup § „Free-riding“ threads in DSTM 2 Coarse transaction granularity ( ¸ 20 accesses per transaction) § Collaborative threads Granularity =1 § 16 threads on 16 cores do random updates on shared ordered list or red-black tree during 10 s. 1 or 8 free-riders High contention Raphael Eidenbenz, ETH Zurich. ISAAC 2009

throughput free-riders (updates/s) Polka throughput collaborators (updates/s) Randomized throughput free-riders (updates/s) Timestamp throughput free-riders (updates/s) Simulation Results throughput free-riders (updates/s) Karma Raphael Eidenbenz, ETH Zurich. ISAAC 2009 throughput collaborators (updates/s)

Good Programming Incentives § A CM is GPI compatible iff it punishes unnecessary locking and rewards partitioning. Raphael Eidenbenz, ETH Zurich. ISAAC 2009

Priority Based CM § CM associates with each thread Ji a priority !i § Thread with highest priority wins conflicts § Rationale: „Don‘t discard the transaction who has done most“ Underlying assumption: Priority measures the amount of work done § E. g. Timestamp CM The oldest transaction has done the most work Theorem: Polite, Greedy, Karma, Timestamp and Polka are not GPI compatible. Raphael Eidenbenz, ETH Zurich. ISAAC 2009

What is wrong? R 1 R 2 R 3 Rs Rs t Raphael Eidenbenz, ETH Zurich. ISAAC 2009 t

What is wrong? R 1 R 2 R 3 Rs t Ø Snatching up resources pushes priority Raphael Eidenbenz, ETH Zurich. ISAAC 2009

More Results Theorem 2: Quasi priority accumulating CMs are not GPI compatible. Theorem 3: Any priority-accumulating CM M is not GPI compatible if one of the following holds: i. M increases a job’s priority on W-events. ii. M increases relative priority on R-events. iii. M schedules transactions gapless and increases priorities on C-events. iv. M restarts aborted transactions immediately and increases priorities on A-events Theorem 4: Any priority-accumulating CM that is based only on time is GPI compatible. Raphael Eidenbenz, ETH Zurich. ISAAC 2009

Randomized CM § Not priority based „Choose random winner“ Lemma 3: Randomized CM is GPI compatible. § Proof Intuition Unnecessary Locks: Stupid because only risk conflict (no priority gain) Partitioning: Ti Ti Ti 1 Ti 2 Raphael Eidenbenz, ETH Zurich. ISAAC 2009 Ti 2

Randomized CM § Not priority based „Choose random winner“ Lemma 3: Randomized CM is GPI compatible. § Proof Intuition Unnecessary Locks: Stupid because only risk conflict (no priority gain) Partitioning: Ti Ti 1 Ti Ti 2 Raphael Eidenbenz, ETH Zurich. ISAAC 2009

Conclusion & Open Problems § Further work: Relax GPI compatibility Trace effect in „real“ software Thank you! Raphael Eidenbenz, ETH Zurich. ISAAC 2009