A Qualitative Survey of Modern Software Transactional Memory Systems Virendra J. Marathe Michael L....

A Qualitative Survey of Modern Software Transactional Memory

Systems

Virendra J. MaratheMichael L. Scott

Software Transactional Memory

Introduction

Introduction

● Herlihy and Moss proposed STM as a novel architectural support mechanism for nonblocking synchronization

Introduction

● Herlihy and Moss proposed STM as a novel architectural support mechanism for nonblocking synchronization

● implemented a transactional memory by extending multiprocessor cache coherency protocols

● provided an instruction set for accessing shared memory

Introduction

● We will see

● Software Transactional Memory (Shavit 95)

● Hash Table Based STM (Harris 03)

● Dynamic Software Transactional Memory (DSTM)

● a Lock Free Object Based STM (FSTM) [Fraser 03]

● We will make a qualitative comparison of these implementations

STM, by Shavit and Toitou[1995]

The STM Algorithm


● The Transaction lists the memory it needs

● The Transaction attempts to take “ownership” of the needed memory

● If any ownerships cannot be taken, the transaction fails and retries

● Change the state to COMITTED atomically

● Make updates

● Release all ownerships


● A memory word is used as the concurrent object

● Each memory word has a corresponding ownership Record (orec)

● The orec may be NULL (no transaction owns the orec)

● The orec may be a reference to a transaction record


Memory Ownership Records

Null

Transaction Record


● Helping– used to avoid livelocks

– Ownerships are acquired in some global order

– if A finds that process B owns a record, A will make B's updates on B's behalf.

– helping is done non-recursively


● Drawbacks– To ensure ordered access, one must know all

memory words one will access before one starts

– each shared memory word requires an orec of equal size. This doubles the memory requirement of STM

– There is an efficiency drawback, due to contention overhead during helping.

Hash Table Based STM

● Word based STM

● Uses a hash table for the orecs

● provides an interface to the STM


● Data Structures– The Application Heap

– The Hash Table of orecs

– transaction descriptors


● Application Heap is the shared memory that holds the data the concurrent processes use

● Uses a hash table for the orecs– The shared memory locations hash into the orecs

hash table.

– Each orec has a version number or a reference to the transaction descriptor of the transaction that currently owns the orec

– When a transaction owns an orec it also owns all other memory hashing into that orec!

Transaction Descriptor

Ownership Record

Application Heap


● The Interface– void STMStart()

– stm_word STMRead( addr a )

– void STMWrite( addr am stm_word w )

– void STMAbort()

– boolean STMCommit()

– boolean STMValidate()

– void STMWait()


Ownership Record

Application Heap

Before


Ownership Record

Application Heap

STMRead or STMWrite

New Transaction Entry :The Address being accessedOld Value and Version num.New Value and Version num


Ownership Record

Application Heap

STMCommit

Address being accessedOld Value and Version num.New Value and Version num


Ownership Record

Application Heap

Read Conflict !


transaction 2

transaction 2


Ownership Record

Application Heap

Acquire Conflict !


transaction 2

transaction 2


● Acquire Conflict :– If the conflicting transaction is ACTIVE the current transaction

aborts it.

– Then the current transaction verifies the consistency of the version number of the orec under conflict with the latest valid version number in the conflicting transaction's descriptor. If an inconsistency is detected, Abort and release all acquired ownerships

– next help or steal


● Stealing vs Helping– Helping is expensive due to contention

– To Steal, the transaction merges the transaction entries corresponding to the orec under conflict into its own transaction descriptor using atomic CAS.


● Design and Efficiency Issues– Contention management, or polite vs aggressive :

polite algorithms perform better

– Bounded Memory Blow-Up Problem : When a stealer merges descriptors, the stealer may end up possessing several records it doesn't care about


● An LL/SC based approach may reduce the effects of the Bounded Memory Blow-Up problem.

Object-based Software Transactional Memory Systems


Dynamic Software Transaction Memory(DSTM)

DSTM

● a Transactional Memory object is a wrapper around the concurrent data object. This contains a pointer to

● a Locator object stores a pointer to a descriptor of the most recent modifying transaction, and to the old and new versions of the data object.

TM Obj.

TransactionNew ObjOld Obj

TransactionNew ObjOld Obj

Committed Transaction

Shared Obj. New Ver.

Shared Obj, Old Ver.

New Active Transaction

Shared Obj, new Vers. Copy

DSTM

● A Transaction Descriptor may be in one of 3 states. These determine the most recent valid version of the data object– ACTIVE : the old version is correct

– ABORTED : the old version is correct

– COMMITTED : the new version is correct

DSTM

● The locator is not an orec– The locator is referenced by the TM object, the orec

is found by a hash function

– The locator points to old and new versions of the data, the orec stores a version number or points to a descriptor with the old and new versions of the data

– The locator does not require a version number


Lock-Free Object Based STM(FSTM)

Lock-Free Object Based STM (FSTM)

● Data Structures– Object Header wraps the concurrent object

– Transaction Descriptor is used by each transaction to maintain the list of in-use concurrent objects. This object maintains two lists (read only and read write)

– Object Handles consist of references to an object header, the concurrent object referenced bu the object header and a shadow copy of the concurrent object.

UNDECIDED

Object Ref, old and new data, next handle

List of object handles

Object Header Concurrent Obj. Shadow Copy


● To access an object– Open the object using that object header

– This creates an object handle in that object's descriptor


● Committing a change– Acquire phase

– Decision Point

– Release Phase


● Acquire Phase– Acquire each concurrent object in read-write object

handle list. Do so in global total order using atomic CAS

– on fail, if the conflict is with a modified object, abort

– on fail, if conflict is with an uncommitted transaction, help the conflicting transaction

– decide whether to commit or abort


● READ-CHECKING state– Decide whether the transactions committed or

aborted

– Begin the read phase, and walk through the descriptor's read-only list

– If there is a conflict, verify the data's consistency

– if the conflict is with an UNDECIDED transaction, verify the old data in the conflicting object handle. If the data object is different, ABORT

The Qualitative Comparison

● Object Acquire Semantics

● Indirection Overhead

● Space Usage

● Search Overhead

● Contention Management vs Helping

● Transaction Validation


● Object Acquire Semantics– Eager Acquire vs Lazy Acquire


● Indirection Overhead– DSTM requires n+1 CAS to commit

– FSTM and Hash Table require 2N+2 CAS


● Space Usage– The space requirement of DSTM is more than twice

that of FSTM usually


● Search Overhead– FSTM and Hash Table require a search for the

concurrent object under conflict

– DSTM does not


● Contention Management vs Helping– need empirical testing of this


● Transaction Validation

A Qualitative Survey of Modern Software Transactional Memory Systems Virendra J. Marathe Michael L....

Documents

Transcript of A Qualitative Survey of Modern Software Transactional Memory Systems Virendra J. Marathe Michael L....