! Part I: Introduction. ! Part II: Obstruction-free STMs. ! DSTM: an obstruction-free STM design. ! FSTM: a lock-free STM design

Transcription

1 genda Designing Transactional Memory ystems Part II: Obstruction-free TMs Pascal Felber University of Neuchatel Part I: Introduction! Part II: Obstruction-free TMs! DTM: an obstruction-free TM design! FTM: a lock-free TM design! L-TM: a time-based TM design ased on joint work with VELOX partners with slides borrowed from several other people! Part III: Lock-based TMs 2/15/11 Transactional Memory: Part II P. Felber 2 Obstruction freedom Why obstruction freedom? ny thread that runs by itself for long enough makes progress vs. Lock freedom ome thread always makes progress! Obstruction freedom argued to be strong enough in practice! Obstruction freedom easier to implement efficiently than lock freedom! First dynamic TM DTM [Herlihy et al., 2003]! No need to know which data will be accessed a priori! -based, Java implementation! Non-blocking (obstruction free)! imple PI Wrapper around ordinary object void begintransaction(); open(tm obj, ED WITE); boolean committransaction(); 2/15/11 Transactional Memory: Part II P. Felber 3 2/15/11 Transactional Memory: Part II P. Felber 4

2 DTM: principle! Problem: update a set of objects atomically! olution:! s accessed indirectly through locators! Transaction state (active, committed, aborted) can be read/updated by other transaction! s must be opened before use! s opened in write mode are only acquired, updates are local until commit! eads are essentially invisible! Incremental validation for consistent reads Why consistent reads?! lthough no damage is done to shared data (consistent writes), inconsistent reads can create program crashes, infinite loops, etc. // Invariant: x + y == 0 // Initially: x = y = 0 TT; a = x; // 0 b = y; // 0 assert(a + b == 0); x = a + 1; // 1 y = b - 1; // -1 OMMIT; // Here: x == 1 && y == -1 TT; a = x; // 0 b = y; // -1 assert(a + b == 0); // Ooops! 2/15/11 Transactional Memory: Part II P. Felber 5 2/15/11 Transactional Memory: Part II P. Felber 6 DTM: data structures DTM: open after commit! Transaction acquires a free object (while opening it) by registering its locator! is free if it does not contain the locator of an active transaction! holds two object versions (old, new) Transaction Old version tatus TIVE OTED OMMITTED data is in new version Transaction 1 Old version New locator Transaction 2 Old version OMMITTED TIVE opy 2/15/11 Transactional Memory: Part II P. Felber 7 2/15/11 Transactional Memory: Part II P. Felber 8

3 DTM: open after abort DTM: conflict management data is in old version Transaction 1 Old version New locator Transaction 2 Old version OTED TIVE opy! onflicts are detected by checking status of owner transaction when opening object! onflicts are handled by a contention manager (M)! Decide which transaction to kill, delay, or let go! To kill a transaction, its status to OTED! M is an independent component (one can register custom Ms)! hoosing the right contention manager is crucial to system throughput 2/15/11 Transactional Memory: Part II P. Felber 9 2/15/11 Transactional Memory: Part II P. Felber 10 DTM: validation, commit, abort! Validation is necessary on open! heck that read versions are still latest! heck that status is still TIVE! ommit requires two phases! Validate read set! state to OMMITTED (atomically update all objects opened in write mode)! Transaction can also abort! state to OTED (atomically release all objects opened in write mode) DTM: obstruction free ny thread that runs by itself for long enough makes progress! transaction T can unilaterally abort other transactions! Hence, T running on its own, can eventually commit 2/15/11 Transactional Memory: Part II P. Felber 11 2/15/11 Transactional Memory: Part II P. Felber 12

4 DTM: costs! Given W objects opened in write mode and in read mode! W + 1! W cloning overhead! O(( + W) ) validation overhead DTM: programming example List public class Node { private int value; private Node next; Node Node Node Node Node MIN MX Non-transactional public Node(int v) { value = v; Transactional public class Node implements TMloneable { private TM next; public void setnext(tm n) { public TM getnext() { public void setvalue(int v) { value = v; public void setnext(node n) { next = n; public int getvalue() { return value; public Node getnext() { return next; public clone() { Node n = new Node(value); n.next = next; return n; 2/15/11 Transactional Memory: Part II P. Felber 13 2/15/11 Transactional Memory: Part II P. Felber 14 DTM: programming example List public class List { private Node head; Node Node Node Node Node MIN MX Non-transactional public List() { Node min = new Node(Integer.MIN_VLUE); Node max = new Node(Integer.MX_VLUE); min.setnext(max); head = min; // Transactional public class List { private TM head; public List() { Node min = new Node(Integer.MIN_VLUE); Node max = new Node(Integer.MX_VLUE); min.setnext(new TM(max)); head = new TM(min); // add(15) DTM: programming example Node Node Non-transactional public boolean add(int v) { Node prev = head; Node next = prev.getnext(); while (next.getvalue() < v) { prev = next; next = prev.getnext(); if (next.getvalue() == v) return false; Node n = new Node(v); n.setnext(prev.getnext()); prev.setnext(n); return true; Transactional public boolean add(int v) { TMThread t = (TMThread)Thread.currentThread(); while (true) { t.begintransaction(); boolean result = false; try { Node prev = (Node)head.open(ED); Node next = (Node)prev.getNext().open(ED); while (next.getvalue() < v) { prev = next; next = (Node)prev.getNext().open(ED); if (curr.getvalue()!= v) { result = true; n.setnext(prev.getnext()); prev = (Node)prev.open(WITE); prev.setnext(new TM(new Node(v))); catch (Denied d) { if (t.committransaction()) return result; 2/15/11 Transactional Memory: Part II P. Felber 15 2/15/11 Transactional Memory: Part II P. Felber 16

5 M: how important? M: how important?! M is essential for performance and livelock avoidance! ample Ms! ggressive: kill enemy! Polite: exponential backoff first // ggressive M void handleonflict(tx me, TX enemy) { enemy.abort();! Karma: increase priority with opened objects and retries, higher priority wins! Timestamp: older transaction wins! Greedy: uses timestamp-based priorities, bounds on worst case completion time 2/15/11 Transactional Memory: Part II P. Felber 17 2/15/11 Transactional Memory: Part II P. Felber 18! s DTM, but:! # implementation XM [Herlihy, 2005]! Use visible reads (maintain reader list)! ingle writer or multiple readers allowed! upport for some advanced patterns! onditional waiting (retry when some object accessed by transaction has been updated)! Or-else combinator (specify alternative to use upon retry) FTM [Fraser, 2003]! Provides lock freedom (stronger than obstruction freedom!)! Implemented using helping (a transaction can help another one)! Uses invisible reads! No extra indirection (i.e., faster data access)! cquire objects at commit time (lazy) 2/15/11 Transactional Memory: Part II P. Felber 19 2/15/11 Transactional Memory: Part II P. Felber 20

6 FTM: data structures FTM: open (write mode) UNDEIDED FILED UEFUL tatus O list /W list Handle Old data New data Next New data Next Header! reate shadow copy (to be updated) and store object in /W list! Note that the write is not visible to other transactions at this point UNDEIDED O list /W list Handle Old data New data Next Header opy 2/15/11 Transactional Memory: Part II P. Felber 21 2/15/11 Transactional Memory: Part II P. Felber 22 FTM: commit 1. cquire the objects in some total order! Header points to the transaction descriptor 2. Decision (after O list validation) 3. elease objects! Header points to new copy UEFUL UNDEIDED O list /W list Handle Old data New data Next Header FTM: lock freedom! ommit phase! multi-word! s are acquired in some total order to ensure lock freedom! ontention is detected when the header points to another transaction! ontention is resolved by order based helping! If header points to the descriptor of another transaction, recursively help it complete! onflict detected if old versions have changed 2/15/11 Transactional Memory: Part II P. Felber 23 2/15/11 Transactional Memory: Part II P. Felber 24

7 FTM: costs! Given W objects opened in write mode and in read mode! 2W + 1! W cloning overhead! O() validation overhead (but may work on inconsistent data!) 2/15/11 Transactional Memory: Part II P. Felber 25 On TM read operations! Visible reads! Maintain reader list per transactional object! an be used to detect /W conflicts (pessimistic)! ontention on reader lists (e.g., root of tree)! Invisible reads! No list of readers is maintained (optimistic)! No easy way to detect /W conflicts! onsistency must be checked (validation)! Validate on commit: may work on inconsistent data! Validate on open: costly (linear w/ read set size)! Goal: low validation costs + consistency 26 On the cost of read operations TM: invisible reads, eager validation XM: visible reads L: time-based invisible reads Invisible reads: validation costs grow linearly Visible reads: cacheline level contention 2/15/11 Transactional Memory: Part II P. Felber 27! Motivation L-TM [iegel et al., 2006]! peed up for transactions with large read sets! Efficient time-based snapshot algorithm (L) to reduce overhead! ead-only transactions! Keep multiple object versions (no abort)! L-TM! -based (uses DTM-like locators)! Java implementation! nnotations and OP for ease of use! Winner of UN s oolthreads contest! 2/15/11 Transactional Memory: Part II P. Felber 28

8 L-TM: algorithm! Global time base: T! ounts the number of commits! s have multiple versions! Each version V has a validity range V w.r.t. T! Most recent version has upper bound! L-TM: algorithm! Transaction maintains a snapshot with a validity range T! Equal to the intersection of the accessed versions' validity ranges! Initialized to [ T,!]! If it becomes empty, transaction must abort 1 1 ommit time 2/15/11 Transactional Memory: Part II P. Felber 29 ommit time 2/15/11 Transactional Memory: Part II P. Felber 30 L-TM: algorithm! Upon read, snapshot is updated! Validity range ends at time of the read! We know that the value read is valid now, but we do not know if it will change in the future L-TM: algorithm! Upon read, if snapshot intersects with the latest version s validity range:! The snapshot is a valid linearization point (as long as there are no writes)! No need to update snapshot 1 1 ommit time ommit time 31 32

9 L-TM: algorithm L-TM: algorithm! Upon read, if snapshot does not intersect with the latest version s validity range:! The snapshot is a not valid linearization point! Must try to extend snapshot (may fail)! Note: read-only transactions can use old version 1 2! Extension tries to increase the upper bound of the snapshot! heck if all versions read are still valid! If so, we can extend the upper bound of the snapshot to current T (now) 1 2 (another TX) ommit time 33 ommit time 34 L-TM: algorithm! Extension may also increase the lower bound of the snapshot! et to the largest lower bound among the validity ranges of accessed versions L-TM: algorithm! ead-only transactions can commit as long as their snapshot is not empty! No need to extend range to current T! Linearization point anywhere in snapshot range ommit time ommit time 35 36

10 L-TM: algorithm L-TM: algorithm! Update transactions create new versions of modified objects upon commit at T! Validity range of newly created object versions starts at T! Tentative versions being written are not visible to other transactions and are discarded upon abort 1 2 W nother TX W ommit time 37! Upon commit, an update transactions tries to acquire a new, unique commit timestamp T! Transaction can commit iff the snapshot can be extended to T - 1 (otherwise, abort)! Note: validation can be skipped if T = T - 1 W 2 W : 1 2 nother TX ommit time 38 L-TM: algorithm [DI 2006] L-TM: algorithm [DI 2006] 2/15/11 Transactional Memory: Part II P. Felber 39 2/15/11 Transactional Memory: Part II P. Felber 40

11 L-TM: # extensions required L-TM: data structures! ead-only transactions! 0 (if enough versions are kept)! Update transactions! 0 or 1 for commit! t most one extension per accessed object! Only caused by concurrent updates to these objects! Disjoint updates do not increase the number of extensions! In practice, only a few extensions are required 41 ame principle as DTM, but maintain timestamps and keep (some) old versions [0] [1] hared clock Transaction Old version Timestamp Older versions Version Timestamp Version Timestamp tatus tart End /W sets TIVE OTED OMMITTED napshot 2/15/11 Transactional Memory: Part II P. Felber 42 L-TM: programming example L-TM: programming example List Node Node Node Node Node MIN MX List Node Node Node Node Node MIN MX public class Node { private int value; private Node next; Non-transactional public Node(int v) { value = v; public void setvalue(int v) { value = v; public void setnext(node n) { next = n; public int getvalue() { return value; public Node getnext() { return public class Node { private int value; private Node next; Transactional public Node(int v) { value = v; public void setvalue(int v) { value = v; public void setnext(node n) { next = public int getvalue() { return public Node getnext() { return next; public class List { private Node head; Non-transactional public List() { Node min = new Node(Integer.MIN_VLUE); Node max = new Node(Integer.MX_VLUE); min.setnext(max); head = min; // public class List { private Node head; Transactional public List() { Node min = new Node(Integer.MIN_VLUE); Node max = new Node(Integer.MX_VLUE); min.setnext(max); head = min; // 2/15/11 Transactional Memory: Part II P. Felber 43 2/15/11 Transactional Memory: Part II P. Felber 44

12 L-TM: programming example L-TM: Linked list add(15) Node Node Just add annotations to transactional objects and atomic methods et voilà! Non-transactional public boolean add(int v) { Node prev = head; Node next = prev.getnext(); while (next.getvalue() < v) { prev = next; next = prev.getnext(); if (next.getvalue() == v) return false; Node n = new Node(v); n.setnext(prev.getnext()); prev.setnext(n); return true; public boolean add(int v) { Node prev = head; Node next = prev.getnext(); while (next.getvalue() < v) { prev = next; next = prev.getnext(); if (next.getvalue() == v) return false; Node n = new Node(v); n.setnext(prev.getnext()); prev.setnext(n); return true; TM: invisible reads, eager validation XM: visible reads L: time-based invisible reads 2/15/11 Transactional Memory: Part II P. Felber 45 2/15/11 Transactional Memory: Part II P. Felber 46 L-TM: Linked list L-TM: Linked list TM: invisible reads, eager validation XM: visible reads L: time-based invisible reads 2/15/11 Transactional Memory: Part II P. Felber 47 TM: invisible reads, eager validation XM: visible reads L: time-based invisible reads 2/15/11 Transactional Memory: Part II P. Felber 48

13 L-TM: kip list L-TM: kip list TM: invisible reads, eager validation XM: visible reads L: time-based invisible reads 2/15/11 Transactional Memory: Part II P. Felber 49 TM: invisible reads, eager validation XM: visible reads L: time-based invisible reads 2/15/11 Transactional Memory: Part II P. Felber 50 L-TM: kip list TM: invisible reads, eager validation XM: visible reads L: time-based invisible reads 2/15/11 Transactional Memory: Part II P. Felber 51 onclusion (Part II)! Obstruction-free TM designs provide progress guarantees (with the help of M)! Transactions must be able to commit atomically and abort another transaction atomically! Typically use indirection (must be able to steal objects)! Lock-free is more complex to implement! Typically based on helping! Time-based designs with invisible reads provide high efficiency and consistency! May be obstruction-free (or not ) 2/15/11 Transactional Memory: Part II P. Felber 52