4
4 The Virtues of Nonblocking Progress Tolerance from arbitrary delays due to Preemption, Page faults, Thread faults External scheduler support mitigates some problems, but Not portable Ideally contain the problem within the STM Environments where blocking is unacceptable TxLinux interrupt handler transactions

7
7 STM Implementations Two types of implementations for speculative writes: Redo Log – writes made to private buffer, and flushed out on commit ownership acquisition can be done at first write (eager acquire) or commit time (lazy acquire) Undo Log – writes are made directly to memory (need eager acquire), old values are logged in a private buffer, and old values are restored in case of an abort Read set validation to ensure isolation Several schemes (e.g. incremental, commit counter, timestamp, etc.)

9
9 What makes nonblocking STMs slow? In Blocking STMs Transaction waits for a conflicting transaction in its post-commit/abort cleanup phase These usually lead to overheads in the (contention-free) common case Nonblocking STMs avoid waiting with Indirection (object-based STMs) Copying and Cloning Helping Stealing (Harris & Fraser; also our approach)

10
10 What makes blocking STMs fast? Significantly less overhead in the common case Simple metadata structure Streamlined fast path Performance optimizations Timestamp based validation We need to incorporate all these features in a nonblocking STM to make it competitive

12
12 Our Contributions Keep the common case simple Resort to complicated case only when cleanup is delayed More streamlined common case execution path Incorporate recent optimizations (timestamp based validation)

13
13 STM Data Structures Word-based STM Conflict detection at granularity of contiguous blocks of memory Appropriate for unmanaged languages – C, C++ A table of ownership records (orecs) Each heap location hashes into a single orec Each orec indicates if currently owned or free, and identifies the owner Transaction Descriptor Read set Write set (redo log) – a 2D list, each row corresponds to an acquired orec Status – Active/Aborted/Committed

14
14 Common Case Execution Algorithm behaves like a blocking STM in the absence of contention Log reads, writes of transaction Acquire ownership of write set locations via their orecs Ensure that reads are still consistent (read set validation) Flush out updates after commit/abort Release orecs

15
15 Uncommon Case: Stealing Two flags in the orec for the stealing process stolen_orec : for orec’s stolen/unstolen state copier_exists : indicates if there exists an owner in cleanup phase

17
17 Stealing Complexity Stealing mechanism quite complex Several corner case race conditions need to be handled (read the paper for further details) Overhead of accessing stolen locations is quite high, requiring a lookup in the last stealer’s write set However, we can throttle stealing and make it an uncommon case

19
19 Timestamps and Validation A significant optimization to read set validation (e.g. TL2) Log time at which orec was modified (done when owner releases orec) A reader checks if the orec was modified after it began execution, and if so, aborts conservatively

20
20 Adding Timestamps Recall: orec contains a pointer to the owner Superimpose a timestamp on this pointer A writer releases orec by storing back the current global time Timestamps lowered the cost of read set validation significantly

21
21 Undo Log Variant We have developed the first nonblocking undo log STM through simple modifications to a redo log variant Stealing of orecs happens in the redo log STM when a committed owner is delayed In undo log STMs stealing largely happens when an aborted owner is delayed Logical values of locations are in aborted owner’s undo log

28
28 Conclusion We presented several variants of a new STM that Effectively decouples the common case from nonblocking infrastructure Enables a more streamlined fast path (comparable to state-of-the-art blocking STMs) Enables integration of key optimizations such as Timestamp-based transaction validation We have shown that common case performance of nonblocking STMs can be made competitive with state-of-the-art blocking STMs

31
31 Basic Idea Transaction steals ownership of the location under conflict Inspired by Harris & Fraser’s WSTM Stealing Requires complex metadata management Leads to high latency reads and writes Switch the stolen location back to unstolen state as quickly as possible

32
32 Phase-I STM: Switching orec back to Unstolen state If an orec is stolen, logical values of mapping locations may be in the last stealer’s write set (pointed by the orec) Stealer will reuse such a write set row (for a new transaction) only after it is reclaimed Subsequent stealer that comes across a stolen orec with ( copier_exists == false ) switches orec to unstolen state Stealing-releasing is a complex process

36
36 Phase-I STM: Stealing Mechanism Steal orec when transaction encounters orec acquired by a committed transaction The committed transaction is copying back its speculative updates Stealing done in two steps: Merge speculative updates of victim to the orec’s locations into stealer’s write set Acquire the orec with an atomic op This involves setting some special flags that indicate to the system that the orec is stolen

37
37 Phase-I STM: Stolen orec state Logical values of stolen locations are always in the stealer’s write set Subsequent accesses to these locations must lookup the stealer’s write set Quite expensive We use some flags to indicate when it is safe for a new stealer to switch the orec back to the unstolen state