Time-based Time-based Transactional Memory Transactional Memory with Scalable Time with Scalable Time Bases Bases Torvald Riegel, Christof Fetzer, Pascal Felber

Presented By:

Michael Gendelman

Time Based Transactional Time Based Transactional MemoryMemory

Uses the notion of time to reason about the consistency of data accessed by transactions and about the order in which transactions commit.

Allows a TM to access consistent objects without the cost of validation.

General DesignGeneral DesignNo specific implementation is

assumed. However, timing information is stored at each object and a cloning mechanism is used to open objects for writing which makes it similar to DSTM by Herlihy et al

Every object has a number of version depending on the implementation

Why are we better ?Why are we better ?1. Avoid large read overhead of TM that

always check consistency when a new object is accessed

2. Current Implementations Basically use a global clock that is incremented by the commit operation for each update transaction. However, in large systems with frequent commits the contention on the counter can become a bottleneck

3. Guaranteed consistency at all times and not only on transaction commit.

Time Bases and UtilitiesTime Bases and UtilitiesGetTime() - returns the current time. It

is assumed that timestamps read by a thread are nonstrict monotonically increasing.

GetNewTS() – returns a strictly greater timestamp then any other return to this thread.

Note: timestamps are not necessarily unique, other threads may read the same timestamps

Time Bases and Utilities Time Bases and Utilities (2)(2)

(t1, t2) – t1 is guaranteed to be later than or equal to t2

(t1, t2) – t1 is possibly greater than t2. Needed for clocks that are not perfectly synchronized

max(t1,t2) – t3 later than max(t1,t2) t3 later than t1and t2

min(t1,t2) – t3 earlier than min(t1,t2) t3 earlier than t1and t2

Validity RangesValidity RangesA new version becomes valid at the time a

transaction that updated the object commits.Validity range is the interval between the time

a version becomes valid and the time it gets replaced by another version.

Some Notations:◦ v.R – validity range of an object version v

e.g. [t1, t2]◦ Lower/Upper bounds:

◦ T.R – Validity range of a transaction. The time range during which all objects versions of a transaction are valid

1 2 2[ , ]t t t 1 2 1[ , ]t t t

What’s in a TransactionWhat’s in a Transaction

T.status is {active, committing, committed, aborted}

What else do we need ?

Read Only TransactionsRead Only Transactions

T11

13 15

o3

o2

o1

o110 o1

14

o212 o2

16

o311 o3

14

V.R = [12, 13]

time

A read only transaction can commit <==> It has a consistent snapshot, which means T.R is not empty

Read only transactions do not have unique commit timestamp as they do not update object

When a transaction T reads an object o that is not yet in T.R: • Look for the most recent version v of o with a validity interval v.R that overlaps T.R. • Compute the new validity interval of the transaction as the intersection of v.R and T.R

The Algorithm (Open)The Algorithm (Open)

Recompute T.Ras intersection of current T.R and v.R of the object version we have

Abort if Range becomes empty

Read Only Tx.

is used to ensure that even if our clocks are not perfectly synchronized we will discover the possibility of an empty range. It will check:t1.ts – t2.ts ≤ t1.dev + t2.dev

The Algorithm (Commit)The Algorithm (Commit)

Only need to set status since nothing was changed during the transaction

Read Only Tx.

Update TransactionsUpdate Transactions When a transaction T tries to update an object o a

private copy of this object is created. We only permit one transaction to acquire a private

copy of an object. If a second transaction T2 attempts to update o before

T committed its changes, we have a write/write conflict. Write/write conflicts are transferred to the Contention

Manager to determine which of the two transactions needs to be aborted (or delayed). In that way, we perform a forward validation of update transactions.

When an update transaction commits, it receives a unique (per thread) timestamp T.CT.

Setting the transaction state {committed, aborted} atomically commits or discards in case of abort all object versions written by the transaction and removes the write marks on all objects.

The Algorithm (Open)The Algorithm (Open)If there is an active writer we must consult with contention mgr. else register as writer

Update Tx.

We loop until we succeed in registering as a writer Must check if the version we opened is not too recent and extend the validity range if possible

Extending the Validity Extending the Validity RangeRange

We try to set the current time as the upper bound of our transaction

Needed when we want to open the most recent version for writing (we never open old versions for writing) and discover it is too recent:

The Algorithm (Open)The Algorithm (Open)

Recompute T.Ras intersection of current T.R and v.R of the object version we have

Abort if Range becomes empty

Update Tx.

The Algorithm (Commit)The Algorithm (Commit)

Atomically commits all object versions written by the transaction and removes the write marks on all objects.

Check that all obj. versions have UB smaller than out tentative commit time.

• Committing state needed so that other threads can help us commit.• This way they will be able to access the latest version we committed.

Update Tx.

Kinds of time basesKinds of time basesPerfectly synchronized real-time

clocks◦ Requires hardware support◦ Each thread has access to a local clock C◦ Clocks are perfectly synchronized at real time t

if C(t) = t

◦ Pros: No contention when processors access their local clock

◦ Cons: Hardware support required

Kinds of time bases (2)Kinds of time bases (2)Externally synchronized real-time

clocks◦ We require that the clock of each thread EC has

a know maximum deviation dev from real time t:

|EC(t) – t| ≤ dev◦ Now when implementing utility functions we

must consider: (timestamp, cid, dev)

◦ Pros: No hardware synchronization support required

◦ Cons: More transaction may be aborted -> decrease in performance

PerformancePerformanceBenchmarks executed on a 16 processor,

Non Uniform Memory Access machine

Benchmarks are not really honest because the chose a machine where shared counters have noticeable overhead

ConclusionsConclusionsA new time based lazy snapshot

algorithm was introducedThe algorithm can use several

different time bases including perfectly synch. clock, and externally synch. clocks.

Real improvements on large multiprocessor machines.