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 or A 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