Advanced Topics in Computing Winter 2009: Reliable Distributed Systems Oved Itzhak

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

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

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- freedom It’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.

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

Ennals’ locking STM

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

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 management can be done without a GC

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

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

McRT-STM’s characteristics May observe inconsistent state Semi-Explicit memory lifecycle management Uses implementation-specific heap

TL locking STM design Locking STM Builds 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 locks Shown by Saha et al. to perform better than R/W-locks

NewOld Transaction TL STM VersionObject Read-set Write-set Object (value) Version lock-word Assoc. Object (value) Bloom Filter

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

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

NewOld Transaction TL STM VersionObject Read-set Write-set Object (value) Version lock-word Assoc. Object (value) Bloom Filter

NewOld Transaction TL STM VersionObject Read-set Write-set Object (value) Version lock-word Assoc. Object (value) Bloom Filter Global Version Clock Version

Locking STMs comparison TL IITLMcRT-STMEnnals’ CMTBothENC ENC/CMT lock Both PO PS/PO Write ENC: Undo CMT: Write Undo Write-set/Undo √---Consistent view √ (only in PS) --Malloc/free

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)

Bibliography Software Transactional Memory Should Not Be Obstruction Free Robert Ennals McRT-STM: A Hogh Performance Software Transactional Memory System for a Multi-Core Runtime Bratin Saha, Ali-Reza Adl-Tabatabai, Richard L. Hudson, Chi Cao Minh, Benjamin Hertzberg Understanding Tradeoffs in Software Transactional Memory Dave Dice, Nir Shavit Transactional Locking II Dave Dice, Ori Shalev, Nir Shavit

Backup

Contention Management Methods Aggressivealways abort Politebackoff before aborting Sensitive to preemption, page-faults etc. Randomized“flip a coin” for backoff Coin bias and backoff time are tunable Kindegartenprioritize according to a partial-order defined by Aborted > Aborted-By

Contention Management Methods Karmaprioritize according to amount of work done Variations: EruptionGive my priority to the conflicting transaction and backoff KillBlockedJust 2 priority levels TimestampFCFS QueueOnBlockbounded-wait

Contention Management Measurements 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