1. Lowering the Overhead of Software Transactional Memory Virendra J. Marathe, Michael F. Spear, Christopher Heriot, Athul Acharya, David Eisenstat, William N. Scherer III, Michael L. Scott Featuring: RSTM – low overhead STM library for C++ Presenting: Yosef Etigin

2. What is this paper about? Design and implementation of RSTM. RSTM is meant to be a fast STM library for C++ multi-threaded programs. RSTM main features: Cache-optimized metadata organization. No memory allocations during runtime, except for cloning objects. Use a contention manager to tune performance. Allow different strategies: eager/lazy acquire, visible/invisible readers.

3. Where RSTM fits in? Requires atomic load/store and CAS in hardware. Provides C++ “Smart Pointers” API that can be used to safely access shared data within transactions. beginTx { openRO, openRW } endTx HW: atomic Load & Store, CAS RSTM Library User application

4. Overview RSTM Theory Transaction Semantics Readers Writers RSTM Design Descriptor Data Object Shared Object Handle RSTM Implementation Resolving the data object Open for read-only Acquire Open for read-write Commit Abort Performance results Conclusion

5. Transaction Semantics Data is considered in object granularity. Objects are shadowed, rather than changed “in place”. Inside a transaction, objects may be opened for read-only or for read-write. Objects that are opened for read-write are cloned, and those for read-only are not. “Commit” tries to set the clone as the current object. “Abort” tries to set the original as the current object. Transactions may abort each other, but they consult the Contention Manager (CM) before doing so.

6. Readers A thread that opens an object for reading may become a “visible” or “invisible” reader. “visible” = visible to writers. Reader must have a consistent view of its opened objects. “consistent” = no writer has made a change that the reader sees only in some of its opened objects. Inconsistency might cause hardware exceptions and infinite loops, thus: Invisible reader, on every “open”, must validate all previously opened objects (O(n 2 ) cost). Visible reader must be explicitly aborted by a writer that acquired it.

7. Writers Opening an object for writing involves “acquiring” it. Acquiring is getting exclusive access to the object. Writers conflict with other writers and with visible readers. Visible readers can co-exist with each other. Acquiring can be done in eager or lazy fashion: Eager – acquire an object as soon as it’s opened. Lazy – acquire it prior to committing the transaction. Eager acquire aborts doomed transactions immediately, but causes more conflicts. Lazy acquire enables readers to run together with a writer that is not committing yet. Has the same consistency issue as with invisible reads.

8. Contention Management CM is a Thread-local object Notified of transaction events Decides what to do on a conflict: Abort a transaction or spin-wait Which transaction to abort, if any For instance: “Polka” CM Prefers writers over readers

9. Overview RSTM Theory Transaction Semantics Readers Writers RSTM Design Descriptor Data Object Shared Object Handle RSTM Implementation Resolving the data object Open for read-only Acquire Open for read-write Commit Abort Performance results Conclusion

10. RSTM Design Descriptor (writer) Shared Object Handle Data Object (New) owner header Data Object (Old) next visible readers Descriptor (reader) Descriptor (reader) Thread 1Thread 2 Thread 3

11. Descriptor Each thread has a static descriptor that is used for all transactions of this thread. Don’t support nested transactions Descriptor has: Status: ACTIVE / COMMITTED / ABORTED Lists of opened objects: Visible, invisible reads. Eager, lazy writes.

12. Data Object Shared objects hold, in addition to data fields, “owner” and “next” fields. Owner is the descriptor of the current writer thread, if any. Next is the original object, if this is a writer- made clone.

13. Shared Object Handle (1) Encapsulates a reference to a shared object. Global variables are handles rather than pointers. Direct pointers are obtained within a transaction, via “open”. Holds: “header” word - identifies the current version of the object. “visible readers” word – bitmap of the visible readers.

14. Shared Object Handle (2) The header is a single word that holds a pointer and a dirty bit. Take advantage of address alignment The pointer holds some data object “pObj”. The dirty bit tells whether “pObj” is a clean object, or a writer-made clone. Saves one dereference in the common case of non-conflicting access.

15. Shared Object Handle (3) “Visible readers” is a bitmap of the visible readers. Bit i of the mask is set if thread i is a visible reader of the object. Allows getting all readers or adding a reader in a single atomic operation. Limits the number of visible readers All others will be invisible

16. Overview RSTM Theory Transaction Semantics Readers Writers RSTM Design Descriptor Data Object Shared Object Handle RSTM Implementation Resolving the data object Open for read-only Acquire Open for read-write Commit Abort Performance results Conclusion

17. RSTM Implementation This section will provide pseudo-code for the most important STM operations: Open object for read-only Open object for read-write Commit Abort We present pseudo-code for methods of Descriptor class, which is the object that implements RSTM functionality.

18. Resolving the Data Object // This function returns the up-to-date data object, associated with // a handle. If the object has an active owner, call CM. Object *Descriptor::resolve(Handle *shared) { long snapshot = shared->header; Object *ptr = snapshot & ~1; // mask out LSB if (snapshot & 1) {// dirty switch (ptr->owner->m_status) { case ACTIVE: m_cm.handleConflict(this, ptr->owner); return NULL; case COMMITTED: return ptr; case ABORTED: return ptr->next; } } else {// clean return ptr; }

19. Open for Read-Only // Open an object for read-only Object *Descriptor::openRO(Handle *shared) { long headerSnapshot = shared->header; // find the data object Object *ptr; do { ptr = resolve(shared); } while (!ptr); if (m_isVisible) { m_visibleReads.add(shared); // install this tx as a visible reader of the object while (! CAS(&shared->readers, shared->readers, shared->readers | (1 << m_id)) ); // make sure no writer acquired this object before he could see the CAS above if (headerSnapshot != shared->header) abort(); } else { m_invisibleReads.add(shared); } validate(); return ptr; }

20. Open for Read-Write // Open an object for read-write Object * Descriptor:: openRW(Handle *shared) { // find the data object Object *ptr; do { ptr = resolve(shared); } while (!ptr); // make a writeable clone Object *clone = ptr->clone(); clone->owner = this; clone->next = ptr; // eager acquires now. lazy acquires later. if (m_isEager) { acquire(shared, clone); m_eagerWrites.add(shared, clone); } else { m_lazyWrites.add(shared, clone); } validate(); return clone; }

21. Acquire // acquire the object void Descriptor::acquire(Handle *shared, Object *clone) { // replace the header with a dirty reference to the clone if (!CAS( &shared->header, shared->header, (long)clone | 1)) abort(); // abort all visible readers for (i = 0; i readers) * 8; ++i) { if (shared->readers & (1 << i)) allDescriptors[i]->abort(); } // record this object for cleanup m_acquiredObjects.add( ); }

22. Commit // commit a transaction void Descriptor::onCommit() { validate(); // acquire now lazily opened-for-rw objects acquireLazyWrites(); // if this CAS succeeds our clones (if any) become the active objects CAS( &m_status, ACTIVE, COMMITTED ); if (m_status == COMMITTED) { // replace a dirty reference to our clone // with a clean reference to our clone for ( in m_acquiredObjects) { CAS( &shared->header, clone | 1, clone ); } for (Shared *shared in m_visibleReads) { while (!CAS( &shared->readers, shared->readers, shared->readers & ~(1 << m_id)) ); } } else { abort(); } Linearization Point

23. Abort // called when “Aborted” exception is caught void Descriptor::onAbort() { // after this CAS, our clones (if any) are discarded CAS( &m_status, ACTIVE, ABORTED ); // cleanup the written objects // replace a dirty reference to our clone // with a clean reference to the original object for ( in m_acquiredObjects) { CAS( &shared->header, clone | 1, clone->next ); } // remove the thread from readers bitmap of all // visibly opened objects for (Shared *shared in m_visibleReads) { while (!CAS( &shared->readers, shared->readers, shared->readers & ~(1 << m_id)) ); }

24. Overview RSTM Theory Transaction Semantics Readers Writers RSTM Design Descriptor Data Object Shared Object Handle RSTM Implementation Resolving the data object Open for read-only Acquire Open for read-write Commit Abort Performance results Conclusion

25. Performance Results (1) Compare ASTM and RSTM (previous work showed that ASTM outperforms DSTM and OSTM). Platform: 16-processor SunFire 6800 at 1.2GHz. Use several benchmarks with different configurations: visible/invisible readers, eager/lazy writers. Each benchmark was run for 10 seconds with 1 to 28 threads. Contention manager: “Polka”. Count successful transactions.

26. Performance Results (2) RSTM with invisible readers is ~2 times better than ASTM. Visible readers are expensive because each access reads the root node and causes cache invalidation. The only difference between C++ ASTM and RSTM is metadata organization.

27. Performance Results (3) In LinkedList, FGL performs bad if #threads > #CPUs due to preemption. In LinkedList, ASTM outperforms RSTM since each writer invalidates objects for many readers. HashTable allows great concurrency, so RSTM works well (~3 times faster than ASTM).

28. Performance Results (4) In RandomGraph and LFUCache, all STM’s perform worse than CGL, because these data structures do not allow much concurrency. Nevertheless, RSTM beats ASTM.

29. Conclusion RSTM has a novel metadata organization which reduces overhead, due to: One level of indirection instead of the common two. Using static instead of dynamic data structures. RSTM provides a variety of policies for conflict detection, so can be customized for a given workload. Compared to ASTM, RSTM gives better performance due to better metadata organization.