Software Transaction Memory for Dynamic-Sized Data Structures presented by: Mark Schall

Software Transaction Memory for Dynamic-Sized

Data Structures

presented by: Mark Schall

The Problem

Using locks introduces well-known problems

Coarse-grained locks:    May block threads when not necessary

Fine-grained locks:    Complex/Error-prone

Dynamic Software Transactional Memory

Synchronize shared data without using locks

Transaction and transaction objects can be created dynamically

Well suited to implement dynamic-sized data structures:    Lists and Trees

Transactions

A sequence of instructions from a single thread  Either commits or aborts  Appears to take effect one after another

Transaction Object: TMObject

Accessed by transactions

Container for a regular Java object

Transactions can open and read or write to the object    

TMObject contd.

Objects encapsulated must implement TMCloneable interface    Requires the object to implement a clone() function

DSTM guarantees during cloning the object will not change

TMObject::open()

Transactions access the encapsulated object by calling the open() method

The thread passes the mode in which to open the object with:    WRITE or READ

open() throws a Denied exception if the object attempted to open was opened by another thread in a conflicting mode.

IntSet Example

Obstruction-Freedom

Simplifies the implementation

Ensures that halted threads cannot prevent other threads from making progress

Does not rule out livelock:    Concurrent threads may repeatedly prevent one another from making progress

Transactions are able to abort other transactions    Allows for prioritizing transactions

IntSet Example contd.

Opening objects not necessary to write in read-only mode may reduce conflicts

Releasing the object will relieve any conflicts other transactions may have with that object

Note: Only can release READ objects

Implementation: Opening TMObjects Each transactional object

has three fields:

Transaction: points to the transaction that created the object

oldObject: points to the original version of the object

newObject: points to the copy/modified version of the object

Conflicting TMObjects::open()

If transaction A tries to open an object already opened by another transaction B

A can abort B orA can wait for B to be aborted or commited

This is determined by the contention manager

Read-only TMObjects::open()

Conflicts with open will be resolved using the contention manager

When opened, the object and the last committed version are stored in a local read-only table

Every read-only open in a transaction will increment a counter in the table to match open(READ) and release() calls

Validating

DSTM must validate an open to ensure the state of the transaction

Validation requires two steps:

1) For each pair of TMObject and encapsulated object in the read only table, verify that the object is still the most recent committed object for the transactional object.

2) Check that the Transaction is still active

Committing

Committing requires validating the entries and changing the status of the transaction to COMMITTED

Contention Manager

Each thread/transaction has a contention manager

Determines whether a transaction should either:    abort another transaction immediately    allow the other transaction a chance to complete

Explicit measures are often necessary to avoid starvation

Its responsibility is progress

Contention managers may consult with each other

Contention Manager Interface

Notification methods:    informs the manager of relevant events

    Success/Failure of commits    Attempts to open objects

Feedback methods:    determine the actions that should be taken in circumstances

    Aborting another transaction

Contention Manager

Correctness (Informally):    "Any active transaction that asks sufficiently many times must eventually get permission to abort a conflicting transaction"

Preserves obstruction freedom

Correctness does not guarantee progress

Contention Manager contd.

Application, environment, and other factors decide policy

Modular implementation allows fine tuning of desired:    progress guarantees     transaction prioritization

Content Management Examples

Aggressive:    Always and immediately grants permission to abort other transactions

Polite:    Adaptively backs off a few times when encountering conflicts       Sleeps for a random amount of time    Any other attempts will double the amount of time    At some threshold the manager will allow an abort

Experiments

Measure the number of operations completed (committed) over a period of 20 seconds

Number of threads varied from 1 and 576 threads

Each operation chose randomly to delete or insert a value from 0 to 255

Results

Conclusions

Contention management schemes are required to avoid livelock

Implementation still requires forethought from programmers