Locking STMs

1. Locking STMs 048961 - Advanced Topics in Computing Winter 2009: Reliable Distributed Systems Oved Itzhak ovedi@tx

2. Agenda • Ennals’ • McRT-STM (Saha et al.’s) • TL (Shavit & Dice) • TL II (Shavit, Dice & Shalev)

3. Original Shavit & Touitou’s STM • Wait/Lock/Obstruction-Free? Lock-Free

4. Ennals’ arguments for using locks • STM will be used mostly for improving the performance of otherwise sequential programs • In the programming paradigms that programmers are accustomed to, correctness does not depend on obstruction-freedomIt’s OK for an atomic operation to wait for other atomic operations at the same or lower priority level • The runtime sees that #Running-tasks == #Cores, thus making it unlikely for a transaction to be blocked by a switched-out transaction • Using locks enables better performance than achieved with obstruction-freedom through • Storing per-object metadata adjacent to the object or in processor private memory • Keep #Active transactions <= #Cores – less conflicts.

5. Ennal’s design • Encounter-order locking • Deadlock and Livelock prevention through Transactions Prioritizationa lower priority transaction cannot abort a higher one • Use Version lock-wordA bit denotes locked/unlocked; The rest contain (Read-) version when not locked and pointer (to transaction metadata) when locked. • Use Write-Bufferingas opposed to Undo-Logging • Per-Object lockNo redirection

6. Ennals’ locking STM

7. Ennals’ characteristics • May observe inconsistent state • Requires managed execution environmentOtherwise may dereference invalid pointers • Requires periodic Read-set validationMay get into infinite loops • Do not support explicit memory lifecycle management (i.e. malloc/free style) (?)

8. McRT-STM’s arguments for using Locks • “Non-Blocking” property should be achieved through the scheduler • There should be much less preemptions in a CMP world – acquired locks are released quickly • Transaction aborts are reduced • Simplified memory managementcan be done without a GC

9. McRT-STM’s design • Encounter-order locking • Deadlock detection through timeout • Simple contention management with the help of McRT’s cooperative schedulerA transation aborts another only if the latter’s thread has yielded • Use Read-versioning/Write-LockingEmpirically, this is much faster that Reader/Writer-Lock • Use Undo-loggingEmpirically, faster than write-buffering • Support both object-based and cache-line-based conflict detection • Support nested transactions

10. McRT-STM’s locking STM LogObject / Version Transaction State Depth Buffer LogObject/ Version Write locks log Next Read locks log Nesting Stack Update log LogObject / OldVal ... …

11. McRT-STM’s characteristics • May observe inconsistent state • Semi-Explicit memory lifecycle managementUses implementation-specific heap

12. TL locking STM design • Locking STMBuilds on Ennals’ and McRT-STM’s rationale • Have different operation modes for performance comparison: • Encounter- vs Commit-order locking • Per-Object (1-1) vs Per-Stripe (1-many) Lock-to-object association • Use Version lock-word locksShown by Saha et al. to perform better than R/W-locks

13. TL STM Assoc. Versionlock-word Object (value) Transaction Read-set Object (value) Write-set Object (value) Versionlock-word Assoc. Assoc. Versionlock-word Object (value) Bloom Filter Object (value)

14. TL STM characteristics • May observe inconsistent state • Explicit memory lifecycle management (i.e. malloc/free style) possible with • Per-Stripe locks-to-objects association • Quiescingto prevent an object from being accessed after it was recycled

15. TL II STM design • Variation of TL: a different versioning scheme • Main advantage: efficient detection of inconsistent memory-view • No need for managed environmentto catch broken invariants • Helps with explicit memory management schemes

16. TL STM Assoc. Versionlock-word Object (value) Transaction Read-set Object (value) Write-set Object (value) Versionlock-word Assoc. Assoc. Versionlock-word Object (value) Bloom Filter Object (value)

17. TL STM Global Version Clock Assoc. Transaction Version Versionlock-word Object (value) Read-set Object (value) Write-set Object (value) Versionlock-word Assoc. Assoc. Versionlock-word Object (value) Bloom Filter Object (value)

18. Locking STMs comparison

19. Some insights • “… contrary to our initial intuition (for the data structures we tested) it is the overhead of the STM implementations (measured, for example, by single thread performance cost) that is best correlated with overall performance…” Shavit& Dice (TL) • “If we could implement fine-grained locking with the same simplicity of course grained, we would never think of building a transactional memory. “ Shavit, Dice & Shalev (TL II Presentation)

20. Bibliography • Software Transactional Memory Should Not Be Obstruction FreeRobert Ennals • McRT-STM: A Hogh Performance Software Transactional Memory System for a Multi-Core RuntimeBratinSaha, Ali-Reza Adl-Tabatabai, Richard L. Hudson, Chi Cao Minh, Benjamin Hertzberg • Understanding Tradeoffs in Software Transactional MemoryDave Dice, Nir Shavit • Transactional Locking IIDave Dice, Ori Shalev, Nir Shavit

21. Backup

22. Contention ManagementMethods • Aggressive always abort • Polite backoff before abortingSensitive to preemption, page-faults etc. • Randomized “flip a coin” for backoffCoin bias and backoff time are tunable • Kindegarten prioritize according to a partial-order defined by Aborted > Aborted-By

23. Contention ManagementMethods • Karma prioritize according to amount of work doneVariations: • Eruption Give my priority to the conflicting transaction and backoff • KillBlocked Just 2 priority levels • Timestamp FCFS • QueueOnBlock bounded-wait

24. Contention ManagementMeasurements • Kidergarten is best in Counter and IntSet benchmarks, most of LFUCache and some of IntSetRelease.However, it’s worst with RBTree. • Karma is best or among the best most other cases. • In some benchmarks several managers provide best performance