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

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

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

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

5. The computation model Starting transaction Read-Transactional(o1)
Write-Transactional(o2)
Read(o3)
Write(o4)
Commit-Transaction

6. 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++

7. and this is why it is called Dynamic Software Transactional Memory
Previous STM designs
Only static memory – need to declare the memory that can be transactioned statically
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
and this is why it is called Dynamic Software Transactional Memory

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

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

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

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

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

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

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

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

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

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

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

19. Opening an object (1)
Let's assume transaction A tries to open 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

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

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

22. 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)

23. 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 (read-only table)

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

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

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

27. 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)

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

29. Ordered Integer List – IntSet (1)
Min 3 4 8
Max 6

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

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

32. Ordered Integer List – IntSet (4)
class IntSet {
boolean insert(int v) {
List newList = new List(v);
TMObject newNode = new TMObject(newList);
TMThread thread = Thread.currentThread();
while (true) {
thread.beginTransaction();
boolean result = true;
try { …
} catch (Denied d) {}
if (thread.commitTransaction())
return result; }

33. Ordered Integer List – IntSet (5)
try {
List prevList = (List)this.first.open(WRITE);
List currList = (List)prevList.next.open(WRITE);
while (currList.value < v) {
prevList = currList;
currList = (List)currList.next.open(WRITE); }
if (currList.value == v) {
result = false;
} else {
result = true;
newList.next = prevList.next;
prevList.next = newNode;

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

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

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

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

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

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

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

41. 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?

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