Lowering the Overheadof Software Transactional MemoryVirendra 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
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.
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
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
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.
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(n2) cost). Visible reader must be explicitly aborted by a writer
that acquired it.
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.
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
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
RSTM Design
Descriptor)writer(
Shared Object Handle
Data Object)New(
owner
header
Data Object)Old(
nextvisiblereaders
Descriptor(reader)
Descriptor)reader(
Thread 1 Thread 2
Thread 3
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.
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.
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.
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.
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
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
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.
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 LSBif (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;}
}
Open for Read-Only// Open an object for read-only Object *Descriptor::openRO(Handle *shared){
long headerSnapshot = shared->header;// find the data objectObject *ptr;do {
ptr = resolve(shared);} while (!ptr);
if (m_isVisible) {m_visibleReads.add(shared); // install this tx as a visible reader of the objectwhile (! CAS(&shared->readers, shared->readers, shared->readers | (1 << m_id)) );// make sure no writer acquired this object before he could see the CAS aboveif (headerSnapshot != shared->header) abort();
} else {m_invisibleReads.add(shared);
}validate();return ptr;
}
Open for Read-Write// Open an object for read-writeObject *Descriptor::openRW(Handle *shared){
// find the data objectObject *ptr;do {
ptr = resolve(shared);} while (!ptr);// make a writeable cloneObject *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;
}
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 < sizeof(shared->readers) * 8; ++i) {
if (shared->readers & (1 << i))
allDescriptors[i]->abort();
}
// record this object for cleanup
m_acquiredObjects.add(<shared, clone>);
}
Commit// commit a transactionvoid Descriptor::onCommit(){
validate();// acquire now lazily opened-for-rw objectsacquireLazyWrites();// if this CAS succeeds our clones (if any) become the active objectsCAS( &m_status, ACTIVE, COMMITTED );
if (m_status == COMMITTED) {// replace a dirty reference to our clone// with a clean reference to our clonefor (<shared, clone> 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
Abort// called when “Aborted” exception is caughtvoid Descriptor::onAbort(){
// after this CAS, our clones (if any) are discardedCAS( &m_status, ACTIVE, ABORTED );// cleanup the written objects// replace a dirty reference to our clone // with a clean reference to the original objectfor (<shared, clone> in m_acquiredObjects) {
CAS( &shared->header, clone | 1, clone->next );}// remove the thread from readers bitmap of all// visibly opened objectsfor (Shared *shared in m_visibleReads) {
while (!CAS( &shared->readers, shared->readers, shared->readers & ~(1 << m_id)) );
}}
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
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.
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.
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).
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.
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.
Top Related