Transactional Memory Lecturer Danny Hendler The Future of

Transactional Memory Lecturer: Danny Hendler

The Future of Computing Speeding up uni-processors is harder and harder Intel, Sun (RIP), AMD, IBM now focusing on “multi-core” architectures Already, most computers are multiprocessors How can we write correct and efficient algorithms for multiprocessors?

A fundamental problem of thread-level parallelism Thread A. . Account[i] = Account[i]-X; Account[j] = Account[j]+X; . . . Thread B. . Account[i] = Account[i]-X; Account[j] = Account[j]+X; . . . But what if execution is concurrent? Must avoid race conditions

Inter-thread synch. alternatives

What is a transaction? • A transaction is a sequence of memory reads and writes, executed by a single thread, that either commits or aborts • If a transaction commits, all the reads and writes appear to have executed atomically • If a transaction aborts, none of its stores take effect • Transaction operations aren't visible until they commit (if they do)

Transactions properties: A transaction satisfies the following key property: • Atomicity: Each transaction either commits (its changes seem to take effect atomically) or aborts (its changes have no effect).

Transactional Memory Goals • A new multiprocessor architecture • The goal: Implementing lock-free synchronization that is – efficient – easy to use compared with conventional techniques based on mutual exclusion • Implemented by hardware support (such as straightforward extensions to multiprocessor cachecoherence protocols) and / or by software mechanisms

A Usage Example Account[i] = Account[i]-X; Account[j] = Account[j]+X; Locks: Lock(L[i]); Lock(L[j]); Account[i] = Account[i] – X; Account[j] = Account[j] + X; Unlock(L[j]); Unlock(L[i]); Transactional Memory: atomic { Account[i] = Account[i] – X; Account[j] = Account[j] + X; };

Transactions interaction • Transactions execute in commit order Time Transaction A Transaction C Transaction B ld 0 xdddd. . . st 0 xbeef Commit 0 xbeef ld 0 xdddd. . . ld 0 xbbbb Commit 0 xbeef ld 0 xbeef Violation! ld 0 xbeef Re-execute with new data Taken from a presentation by Royi Maimon & Merav Havuv, prepared for a seminar given by Prof. Yehuda Afek.

Software Transactional Memory for Dynamic-Sized Data Structures (DSTM – Dynamic STM) Maurice Herlihy, Victor Luchangco, Mark Moir, William N. Scherer III Prepared by Adi Suissa PODC 2003

Motivation • Transactional Memory – simplifies parallel programming • STM – Software based TM ▫ Usually simpler than Hardware based TM ▫ Can handle situations where HTM fails • However: ▫ It is immature (supports static data sets and static transactions) ▫ It is complicated

Overview • • Short recap and what’s new? How to use DSTM? Example Diving into DSTM Example 2 Improving performance Obstruction freedom

Transactions • Transaction – a sequence of steps executed by a single thread • Transactions are atomic: each transaction either commits (it takes effect) or aborts (its effects are discarded) • Transactions are linearizable: they appear to take effect in a one-at-a-time order

The computation model Starting transaction Read-Transactional(o 1) Write-Transactional(o 2) Read(o 3) Write(o 4) Commit-Transaction

The computation model • Committing a transaction can have two outcomes: ▫ Success: the transaction’s operations take effect ▫ Failure: the operations are discarded • Implemented in Java and in C++

Previous STM designs • Only static memory – need to declare the and this is why it is called Dynamic memory that can be transactioned statically Software Transactional Memory ▫ We want the ability to create transactional objects dynamically • Only static transactions – transactions need to declare which addresses they are going to access before the transaction begins ▫ We want to let transactions determine which object to access based on information of objects read inside a transaction

Overview • • Short recap and what’s new? How to use DSTM? Example Diving into DSTM Example 2 Improving performance Obstruction freedom

Threads • A thread that executes transactions must be inherited from TMThread class TMThread : Thread { void begin. Transaction(); bool commit. Transaction(); void abort. Transaction(); } Don’t forget the run() method • Each thread can run a single transaction at a time

Objects (1) • All shared memory objects must implement the TMCloneable interface: inteface TMCloneable { Object clone(); } • This method clones the object, but clone implementors don’t need to handle synchronization issues

Objects (2) • In order to make an object transactional, need to wrap it TMObject • TMObject is a container for regular Java objects

Opening an object • Before using a TMObject in a transaction, it must be opened class TMObject { TMObject(Object obj); enum Mode {READ, WRITE}; Object open(Mode mode); } • An object can either be opened for READ or WRITE (and read)

Overview • • Short recap and what’s new? How to use DSTM? Example Diving into DSTM Example 2 Improving performance Obstruction freedom

An atomic counter (1) • The counter has a single data member and two operations: class Counter : TMCloneable { int counter. Value = 0; } void inc(); // increment the value int value(); // returns the value Object clone(); • The object is shared by multiple threads

An atomic counter (2) Counter counter = new Counter(); TMObject tran. Counter = new TMObject(counter); • When a thread wants to access the counter in a transaction, it must first open the object using the encapsulated version: ((TMThread)Thread. current. Thread). begin. Transaction(); … Returns true/false Counter counter = (Counter)tran. Counter. open(WRITE); to indicate commit counter. inc(); status … ((TMThread)Thread. current. Thread). commit. Transaction();

Overview • • Short recap and what’s new? How to use DSTM? Example Diving into DSTM Example 2 Improving performance Obstruction freedom

DSTM implementation • Transactional object structure: transaction start TMObject status new object old object Data Locator Data

Current object version • The current object version is determined by the status of the transaction that most recently opened the object in WRITE mode: ▫ committed: the new object is the current ▫ aborted: the old object is the current ▫ active: the old object is the current, and the new is tentative • The actual version only changes when a commit is successful

Opening an object (1) • Let's assume transaction A opens object o in WRITE mode. • Let transaction B be the transaction that most recently opened o in WRITE mode. • We need to distinguish between the following cases: ▫ B is committed ▫ B is aborted ▫ B is active

Opening an object (2) – B committed transaction start o 4 Use CAS in order to replace locator Data new object old object Data Locator If B’s CAS fails, A restarts from the beginning transaction active new object Data old object A’s Locator 3 1 A sets creates old aobject new Locator to the previous new 2 A clones the previous new object, and sets new clone

Opening an object (3) – B aborted transaction start o 4 Use CAS in order to replace locator Data new object old object Data B’s Locator transaction active new object Data old object A’s Locator 3 1 A sets creates old aobject new Locator to the previous old 2 A clones the previous old object, and sets new clone

Opening an object (4) – B active • Problem: B is active and can either commit or abort, so which version (old/new) should we use? • Answer: A and B are conflicting transactions, that run at the same time • Use Contention Manager to decide which should continue and which should abort • If B needs to abort, try to change its status to aborted (using CAS)

Opening an object (5) • Lets assume transaction A opens object o in READ mode ▫ Fetch the current version just as before ▫ Add the pair (o, v) to the readers list (readonly table)

Committing a transaction • The commit needs to do the following: 1. Validate the transaction 2. Change the transaction’s status from active to committed (using CAS)

Validating transactions • What? ▫ Validate the objects read by the transaction • Why? • If the validation fails, throw an ▫ To make sure that the transaction exception so the user will consistentrestart statethe transaction from the beginning How? observes a 1. For each pair (o, v) in the read-only table, verify that v is still the most recently committed version of o 2. Check that (status == active)

Validation inconsistency • Assume two threads A and B Thread A 1. x <- read(o 1) 2. w(o 2, x + 1) Thread B 1. y <- read(o 2) 2. w(o 1, y + 1) Initially: o 1 = 0 o 2 = 0 • If B after A, then o 1 = 2, o 2 = 1; • If A after B, then o 1 = 1, o 2 = 2 • If they run concurrently we can have o 1 = 1, o 2 = 1 which is illegal

Conflicts • Conflicts are detected when: ▫ A transaction first opens an object and finds that it is open for modification by another transaction ▫ When the transaction validates its read set (on opening an object or commit)

Overview • • Short recap and what’s new? How to use DSTM? Example Diving into DSTM Example 2 Improving performance Obstruction freedom

Ordered Integer List – Int. Set (1) Min 3 4 8 6 Max

Ordered Integer List – Int. Set (2) class List implements TMCloneable { int value; TMObject next; List(int v) { value = v; } } public Object clone() { List new. List = new List(value); new. List. next = next; return new. List; }

Ordered Integer List – Int. Set (3) class Int. Set { TMObject first; // the list’s anchor } Int. Set() { List first. List = new List (Integer. MIN_VALUE); first = new TMObject(first. List); first. List. next = new TMObject( new List(Integer. MAX_VALUE)); }

Ordered Integer List – Int. Set (4) class Int. Set { boolean insert(int v) { List new. List = new List(v); TMObject new. Node = new TMObject(new. List); TMThread thread = Thread. current. Thread(); while (true) { thread. begin. Transaction(); boolean result = true; try { … } catch (Denied d) {} if (thread. commit. Transaction()) return result; } } }

Ordered Integer List – Int. Set (5) try { } List prev. List = (List)this. first. open(WRITE); List curr. List = (List)prev. List. next. open(WRITE); while (curr. List. value < v) { prev. List = curr. List; curr. List = (List)curr. List. next. open(WRITE); } if (curr. List. value == v) { result = false; } else { result = true; new. List. next = prev. List. next; prev. List. next = new. Node; }

Overview • • Short recap and what’s new? How to use DSTM? Example Diving into DSTM Example 2 Improving performance Obstruction freedom

Single entrance • What is the problem with the previous example? • How can it be solved? ▫ Opening for READ on traversal ▫ Maybe something more sophisticated?

Releasing an object • An object that was open for READ can be released • What does it imply? ▫ Careful planning ▫ Can increase performance ▫ What happens if we open an object, release it and open it again in the same transaction? ▫ Can lead to validation problems

Overview • • Short recap and what’s new? How to use DSTM? Example Diving into DSTM Example 2 Improving performance Obstruction freedom

Non-Blocking Algorithms • A family of algorithms on a shared data • Each sub-family satisfies different progress guarantees • Usually, there is a correlation between the progress guarantee strength and the complexity of the algorithm

Wait-Free algorithms • An algorithm is wait-free if every operation has a bound on the number of steps it will take before completing No Starvation

Lock-Free algorithms • An algorithm is lock-free if every step taken achieves global progress • Even if n-1 processes fail (while doing operations on the shared memory), the last processor can still complete its operation • Example: Shavit & Touitou’s STM implementation

Obstruction-Free algorithms • An algorithm is obstruction-free if at any point, a single thread executed in isolation for a bounded number of steps will complete its operation • Doesn’t avoid live-locks • Example: DSTM implementation • What is it good for?

Contention Manager (CM) • The contention manager arbitrates between two conflicting transactions • Given two (conflicting) transactions TA, TB, then CM(TA, TB): 1. Decides who wins 2. Decides what the loser should do (abort/wait/retry) • Conflicts policy

Questions?