1. Software Transactional Memory for Dynamic-Sized Data Structures Maurice Herlihy, Victor Luchangco, Mark Moir, William Scherer Presented by: Gokul Soundararajan

2. 2 Outline Background Background Software Transactional Memory (STM) Software Transactional Memory (STM) –Implementation –Long Example Experimental Results Experimental Results Conclusion Conclusion

3. 3 Transaction A sequence of operations on components of a data structure executed by a single thread Atomic Atomic: either – –Commits: takes effect – –Aborts: its effects are discarded Linearizable: preserves program order

4. 4 Transactional Memory Any system that supports concurrent execution of transactions performed by threads Originally, a hardware idea Now, implemented in software

5. 5 Transactional Objects container Is a container for a regular object A transaction accesses it – –Open – –Read/modify – –Changes are not seen until the transaction commits Creation and initialization of a transactional object is not a part of any transaction

6. 6 DSTM Implementation container Is a container for a regular object TMObject class TMObject class –Implements a transactional object Class: TMObject Locator {Transaction, oldObject, newObject} Locator * start open( ) release( )

7. 7 DSTM Implementation transaction oldObject newObject The transaction that most recently opened the object in WRITE mode A new object version An old object version start TMObject Locator

8. 8 Current Version Current version of a transactional object Current version of a transactional object –Determined by the status of the transaction (T) that most recently opened the object in WRITE mode T Status Current Version Other Version COMMITTEDnewObjectmeaningless ABORTEDoldObjectmeaningless ACTIVEoldObjectTentativeVersion

9. 9 Open(WRITE): T is COMMITTED transaction oldObject newObject T: COMMITTED newVersion oldVersion start myObj

10. 10 Open(WRITE): T is COMMITTED transaction oldObject newObject T: COMMITTED newVersion oldVersion start transaction oldObject newObject A: ACTIVE A opens myObj in WRITE mode myObj

11. 11 Open(WRITE): T is COMMITTED transaction oldObject newObject T: COMMITTED newVersion oldVersion start transaction oldObject newObject A: ACTIVE Copy of newVersion A opens myObj in WRITE mode myObj copy

12. 12 Open(WRITE): T is COMMITTED transaction oldObject newObject T: COMMITTED newVersion oldVersion start transaction oldObject newObject A: ACTIVE Copy of newVersion A opens myObj in WRITE mode myObj copy

13. 13 Open(WRITE): T is COMMITTED transaction oldObject newObject T: COMMITTED newVersion oldVersion start transaction oldObject newObject A: ACTIVE Copy of newVersion A opens myObj in WRITE mode myObj copy CAS

14. 14 Open(WRITE): T is ABORTED transaction oldObject newObject T: ABORTED newVersion oldVersion start transaction oldObject newObject A: ACTIVE A opens myObj in WRITE mode myObj

15. 15 Open(WRITE): T is ABORTED transaction oldObject newObject T: ABORTED newVersion oldVersion start transaction oldObject newObject A: ACTIVE Copy of oldVersion A opens myObj in WRITE mode myObj copy

16. 16 Open(WRITE): T is ABORTED transaction oldObject newObject T: ABORTED newVersion oldVersion start transaction oldObject newObject A: ACTIVE Copy of oldVersion A opens myObj in WRITE mode myObj copy

17. 17 Open(WRITE): T is ABORTED transaction oldObject newObject T: ABORTED newVersion oldVersion start transaction oldObject newObject A: ACTIVE Copy of oldVersion A opens myObj in WRITE mode myObj copy

18. 18 Open(WRITE): T is ACTIVE transaction oldObject newObject T: ACTIVE newVersion oldVersion start transaction oldObject newObject A: ACTIVE A opens myObj in WRITE mode myObj A tries to abort T ?

19. 19 Example: Integer Set Specifications: Specifications: –Object: Integer Set –Supports:  insert(v)  delete(v)  member(v) Implementation: Implementation: –Linked list of a set of elements –Sorted in ascending order

20. 20 Integer Set Example: Constructor MIN next MAX next start

21. 21 Integer Set Example: insert(40) MIN next MAX next -20 next 30 next first thread 40 next newElm T ACTIVE start T COMMITED start newNode

22. 22 Integer Set Example: insert(40) MIN next MAX next -20 next 30 next MIN next first thread 40 next newElm T ACTIVE start T N O T COMMITED start newNode

23. 23 Integer Set Example: insert(40) MIN next MAX next -20 next 30 next MIN next first thread -20 next 40 next newElm T ACTIVE start T N O T N O T COMMITED start newNode

24. 24 Integer Set Example: insert(40) MIN next MAX next -20 next 30 next MIN next first thread -20 next 40 next newElm 30 next T ACTIVE start T N O T N O T N O T COMMITED start newNode

25. 25 Integer Set Example: insert(40) MIN next MAX next -20 next 30 next MIN next first thread -20 next 40 next newElm 30 next T ACTIVE start T N O T N O T N O T COMMITED start newNode

26. 26 Integer Set Example: insert(40) MIN next MAX next -20 next 30 next MIN next first thread -20 next 40 next newElm 30 next MAX next T ACTIVE start T N O T N O T N O T N O T COMMITED start newNode

27. 27 Integer Set Example: insert(40) MIN next MAX next -20 next 30 next MIN next first thread -20 next 40 next newElm 30 next MAX next T ACTIVE start T N O T N O T N O T N O T COMMITED start newNode

28. 28 DSTM and Sequential Code Differences: –Need to catch Denied exception –Retry transaction that fails to commit –Distinguish between transactional objects and non-transactional objects

29. 29 Obstruction Freedom Guarantees progress for any thread that eventually executes without interference for a sufficient number of steps Guarantees progress for any thread that eventually executes without interference for a sufficient number of steps Strong enough to avoid problems associated with locks Strong enough to avoid problems associated with locks Ensures that no thread can be blocked by delays or failures of other threads Ensures that no thread can be blocked by delays or failures of other threads Live-lock Live-lock –Livelock Freedom - If some process wants to enter the critical section, then some process will eventually enter the critical section.

30. 30 Obstruction Freedom Weaker progress guarantee than wait-freedom Weaker progress guarantee than wait-freedom –All processes are guaranteed to complete the access in finite time, regardless of the actions of the other processes. BUT: BUT: Efficient Contention Manager + Obstruction Freedom Wait Freedom In Practice

31. 31 Contention Management Methods: Methods: –Aggressive  Abort the conflicting transaction  Interrupting a partially executed operation will not jeopardise correctness –Polite  Operations “back off” when they encounter interference  Wait for some time before retrying

32. 32 Contention Management Contention manager is invoked only in case of contention Contention manager is invoked only in case of contention In most lock-free and wait-free implementations, mechanisms used to ensure progress impose significant overhead even in the absence of contention In most lock-free and wait-free implementations, mechanisms used to ensure progress impose significant overhead even in the absence of contention

33. 33 Experiments Benchmarks Benchmarks –IntSet –IntSet with Early Release –RBTree Contention Management Contention Management –Aggressive – abort the conflicting transaction –Polite – have a back-off algorithm

34. 34 Results

35. 35 Results

36. 36 Results

37. 37 Results

38. 38 Conclusion Presented Presented –Transactional Memory in Java/C++ –Probably easier in Java (because of the Object data type) –Good performance over simple locking