Virendra J. Marathe, William N. Scherer III, and Michael L. ScottDepartment of Computer ScienceUniversity of Rochester

Presented by: Armand R. Burks Fall 2008

Classic lock-based implementations of concurrent objects suffer from several important drawbacks: Deadlocks Priority inversion Convoying Lack of fault tolerance

Increased interest in nonblocking synchronization algorithms Failure of a thread can never prevent the

system from making forward progress

A concurrent object is a data object shared by multiple threads of control within a concurrent system.

Section 1 – IntroductionSection 2 – DSTMSection 3 – FSTMSection 4 – Comparative Evaluation

Section 5 – Related WorkSection 6 - Conclusions

Section 1:

Introduction

STM – an approach to construct nonblocking objects Simplifies task of implementing concurrent

objects Software Transactional Memory (STM) is

a generic non-blocking synchronization construct that enables automatic conversion of correct sequential objects into correct concurrent objects.

Transaction A finite sequence of instructions (satisfying

the linearizability and atomicity properties) that is used to access and modify concurrent objects

This paper focuses on discussing two approaches to STM

Compares and evaluates strengths and weaknesses of the approaches

Section 2:

Dynamic Software Transactional Memory

Definition... DSTM is a low-level application

programming interface (API) for synchronizing shared data without using locks. (Herlihy)

Uses early release ( a transaction can drop a previously opened object)

Invisible reads Example follows...

Start

TMObject Locator

Committed Transaction

Shared Object-Old

Version

Shared Object-New

Version

Transaction

Old Object

New Object

Transaction

New Object

Old Object

New Locator

Old Locator

New Active Transaction

Shared Object-New

Version

Copy

Atomic Compare & Swap (CAS)CAS FAILURE

X

Other transaction

has acquired

object

Opening a TMObject (in write mode) recently modified by a committed transaction

Most recent previous transaction may still be ACTIVE Wait/retry, abort, or force competitor to

abort Ask contention manager to make decision

Full acquire operation Unnecessary contention between

transactions How do we avoid this contentention?

Each transaction maintains private (read-list) of objects opened in read-only mode

Must recheck validity before committing

What about stale data (from a not yet

committed transaction)? May lead to unwanted behavior ( addressing

errors, infinite loops, division by zero, etc.) Transaction would have to revalidate all

open read-only objects Current version does this automatically

when opening

Section 3:

Fraser’s Software Transactional Memory

(FSTM)

Named after Keir Fraser (Cambridge) Unlike DSTM, FSTM is lock-free

Guarantees forward progress for system (within a bounded number of steps, some thread is guaranteed to complete a transaction)

How? Recursive helping

When transaction detects conflict with another, it uses the conflicting transaction’s descriptor to make updates, then aborts/restarts itself. Example follows:

B

B A

COMMITTED

AAbort & Restart

A

Concurrent Object

A

COMMITTED

Concurrent Object

Shadow Copy

Object Header

Transaction Descriptor

UNDECIDED

Status

Read-onlyRead-write

Object Handles

Unlike DSTM, multiple transactions can open the same object in write mode because each has its own shadow copy.

UNDECIDED ABORTED COMMITTED READ-CHECKING

UNDECIDED Transaction opens object headers while in

this state Open is not visible to other transactions

COMMITTEDIf open by another transaction, will be detectedIf conflict is detected, the transaction uses

recursive helping

Transaction acquires all objects it opened in write mode in some global total order (virtual address) Uses atomic Compare and Swaps

Each CAS swings object header’s pointer to transaction descriptor

If pointer already points to another transaction’s descriptor, conflict is detected

Example follows

Concurrent Object

Shadow Copy

Object Header

Transaction Descriptor

UNDECIDED

Status

Read-onlyRead-write

Object Handles

CAS

Recursively help competitor

Only proceeds if competitor precedes in in global total order (thread/transaction id)

If not, competitor will be aborted Also, competitor must be in READ-

CHECKING state (for validating)

Validates objects in read-only list Verify object header still points to version of

object as when handle was created If not, abort If pointing to another transaction, recursively

help

After successful validation, switch to COMMITTEDDone automatically by transactionRelease object by swinging handle to new version

Section 4:

Comparative Evaluation

Both DSTM and FSTM have significant overhead Simpler than previous approaches

This section does the following Highlight design tradeoffs between the two Highlight impact on performance of various

concurrent data structures

16-processor SunFire 6800 Cache-coherent multiprocessor

1.2 GHz Processors Environment – Sun’s Java 1.5 beta 1

HotSpot JVMAugmented with JSR166 update from Doug Lea

Simple Benchmarks A stack 3 variants of a list-based set

More Complex Benchmark Red-black tree

In list and Red-black tree benchmarks Repeatedly/Randomly insert/delete integers 0-255

Keeping this range small increases probability of contention

Measured total throughput over 10 seconds

Vary number of worker threads between 1-48

Six test runs

DSTM Transaction acquires exclusive access when it

first opens it for write access Makes transaction visible to potential competitors

early in its lifetime (eager acquire)

FSTM Transaction acquires exclusive access only in

commit phase Makes transaction visible to potential

competitors later in its lifetime (lazy acquire)

Eager acquire Enables earlier detection & resolution of

conflicts

Lazy acquire May cause transactions to waste computational

resources on doomed transactions before detecting a conflict

Tends to reduce amount of transactions identified as competitors If application semantics allow both transactions to commit, lazy

acquire may result in higher concurrency

Red-black Tree Performance Results

FSTM outperforms due to lazy acquire semantics

Number of Contention Instances

FSTM outperformed again Difference remained more or less constant

DSTM has extra level of indirection (Fig 1. & 2) TMObject points to Locator which points to

object data FSTM object header points directly to object

data

Extra indirection may result in slower reads/writes

Slower transactions (particularly if most are read-only)

Indirection eliminates overhead of inserting object handles into descriptor chains Transactions with large number of writes

may be faster in DSTM Lazy acquire requires extra bookkeeping

Testing Benchmarks Stack, IntSet, IntSetRelease

Stack Performance Results

Stack illustrates very high contention (top-of-stack pointer)

DSTM outperformance Due to FSTM extra bookkeeping in write

mode

IntSet maintains sorted list Every insert/delete opens (write mode) all

objects from beginning of list Successful transactions are serialized

IntSet Performance Results

Higher throughput for DSTM FSTM suffers extra bookkeeping

overhead, sorting overhead, and extra CASes

IntSetRelease – variant of IntSet Only the object to be modified is opened in

write mode All others opened temporarily in read

mode Then either released (moving on to next node

in list) Or upgraded to write mode

IntSetRelease Performance Results

FSTM more than a factor of 2 better DSTM’s indirection is to blame

Invisible reads & lazy acquire (FSTM) may allow transaction to enter inconsistent state during execution This may lead to memory access violations,

infinite loops, arithmetic faults, etc. DSTM- performs incremental validation at

open time FSTM- proposes mechanism based on

exception handling (catch problems when they arise rather

than prevent them)

On a memory access violation, exception handler validates the transaction that caused the exception

Responsibility of detecting other inconsistencies is left to the programmer

IntSetUpgrade Similar to IntSetRelease

Opens in write mode only if object needs to be changed

The fact that most objects are read-only introduces some concurrency

IntSetUpgrade Performance Results

Incremental validation introduces dramatic overhead in both systems Results suggest potential benefits from

using application-specific reasoning to eliminate need (or at least frequency of) incremental validation

Related Work&

Conclusions

Harris & Fraser – word-based STM Hashes shared memory words into

ownership records Transaction acquires records before

updating Harris & Fraser – novel stealing mechanism

Avoids cache thrashing that might result from recursive helping

Cole & Herlihy – optimization to DSTM to reduce bookkeeping overhead in read mode

Paper evaluated tradeoffs in design of practical, object-based STM systems

DSTM tends to do better for transactions in write mode Early detection & avoidance of bookkeeping Both systems incur significant overhead for

read-only Acquire semantics play key role in

performance