1 / 35

Software Transactional Memory for Dynamic-Sized Data Structures (DSTM – Dynamic STM)

Software Transactional Memory for Dynamic-Sized Data Structures (DSTM – Dynamic STM). Maurice Herlihy, Victor Luchangco, Mark Moir, William N. Scherer III. PODC 2003. Presentation prepared by Adi Suissa for TM seminar, fall 2008/9. Overview. Short recap and DSTM contributions

caitir
Télécharger la présentation

Software Transactional Memory for Dynamic-Sized Data Structures (DSTM – Dynamic STM)

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  1. Software Transactional Memory for Dynamic-Sized Data Structures(DSTM – Dynamic STM) Maurice Herlihy, Victor Luchangco, Mark Moir, William N. Scherer III PODC 2003 Presentation prepared by Adi Suissa for TM seminar, fall 2008/9

  2. Overview • Short recap and DSTM contributions • How to use DSTM? • Example • Diving into DSTM • Example 2 • Improving performance

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

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

  5. Comparison with the Shavit-Toutitou TM • 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 • Obstruction-free (rather than non-blocking)

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

  7. Threads • A thread that executes transactions must inherit from TMThread • Each thread can run a single transaction at a time class TMThread : Thread { void beginTransaction(); boolcommitTransaction(); void abortTransaction(); }

  8. Objects (1) • All TM objects must implement the TMCloneable interface: • This method clones the object, but programmers don’t need to handle synchronization issues intefaceTMCloneable { Object clone(); }

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

  10. 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); }

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

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

  13. 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(); TMObjecttranCounter = 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

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

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

  16. 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 the commit succeeds

  17. Opening an object (1) • Lets 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

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

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

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

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

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

  23. Validating transactions • What? • Validate the objects 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

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

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

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

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

  28. 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; } } Should have been called Element

  29. 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)); } }

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

  31. 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; } }

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

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

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

  35. Questions?

More Related