1. Time-based Transactional Memory with Scalable Time Bases Torvald Riegel, Christof Fetzer, Pascal Felber Presented By: Michael Gendelman

2. Time Based Transactional Memory 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.

3. General Design No 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

4. 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.

5. Time Bases and Utilities GetTime() - 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

6. Time Bases and Utilities (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

7. Validity Ranges A 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

8. Whats in a Transaction T.status is {active, committing, committed, aborted} What else do we need ?

9. Read Only Transactions T 111315 o3o3 o2o2 o1o1 o 1 10 o 1 14 o 2 12 o 2 16 o 3 11 o 3 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

10. The Algorithm (Open) Recompute T.R as 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

11. The Algorithm (Commit) Only need to set status since nothing was changed during the transaction Read Only Tx.

12. Update 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.

13. 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

14. Extending the Validity Range 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:

15. The Algorithm (Open) Recompute T.R as intersection of current T.R and v.R of the object version we have Abort if Range becomes empty Update Tx.

16. 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.

17. Kinds of time bases Perfectly 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

18. 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

19. Performance Benchmarks 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

20. Conclusions A new time based lazy snapshot algorithm was introduced The algorithm can use several different time bases including perfectly synch. clock, and externally synch. clocks. Real improvements on large multiprocessor machines.