1. EPFL - March 7th, 2008 Interfacing Software Transactional Memory Simplicity vs. Flexibility Vincent Gramoli

2. EPFL - March 7th, 2008 Multi-core Motivations 1.Transistor size allows multi-core

3. EPFL - March 7th, 2008 Multi-core Motivations 1.Transistor size allows multi-core 2.Processor speed is power-consuming

4. EPFL - March 7th, 2008 Multi-core Motivations 1.Transistor size allows multi-core 2.Processor speed is power-consuming 3.Limiting computation speed

5. EPFL - March 7th, 2008 S oftware T ransactional M emory Motivations Simplicity while handling efficiently parallelism: –Avoiding inefficient coarse-grained locking –Avoiding tricky fine-grained locking –Allowing composition of transactions –Providing transparency to programmer Here it is: Software Transactional Memory –Execute code optimistically –Detect conflict when it occurs –Roll-back in case it aborts

6. EPFL - March 7th, 2008 Goal Making STM simple and flexible! 1.Making STM simple: Any programmer should be able to use it 2.Making STM flexible: STM should be efficient in any situations

7. EPFL - March 7th, 2008 Overview 1.Preliminaries 2.Making STM easy-to-use 3.Making STM flexible 4.Reconciling simplicity and flexibility

8. EPFL - March 7th, 2008 What is an interface? “The interactions of an object with the outside world.” [java.sun.com]

9. EPFL - March 7th, 2008 Interfacing STM ApplicationSTM beginTransaction() endTransaction()

10. EPFL - March 7th, 2008 Interfacing STM ApplicationSTM beginTransaction() endTransaction() onAbort() onCommit() Abort handler Commit handler

11. EPFL - March 7th, 2008 Interfacing STM 1.Is the abort handler part of the STM? 2.Is the commit handler part of the Application? 3.What should be defined explicitly?

12. EPFL - March 7th, 2008 Overview 1.Preliminaries 2.Making STM easy-to-use 3.Making STM flexible 4.Reconciling simplicity and flexibility

13. EPFL - March 7th, 2008 Guards Explicit Semantic [Harris, Fraser in OOPSLA’03]: If* (B) Do (A) where A is the atomic block, B is a boolean (guard) * can also act as a “wait” (e.g. B=!full_stack) Implicit Requirement: Implicit maximum number of retries B = #retries < ? How many retries should be made?

14. EPFL - March 7th, 2008 Retries Explicit Semantic [Harris, Marlow, Peyton Jones, Herlihy, PPoPP’05]: Do (A) If (B) Retry Implicit Requirement: Implicit roll-back if B is true Which previous actions should be canceled?

15. EPFL - March 7th, 2008 Exceptions Explicit Semantic [Fetzer, Felber in J.UCS’07]: Do (A) If (B) Do (C) Implicit Requirement: Implicit identification of the cause of the exception How can we prevent this exception to raise again ?

16. EPFL - March 7th, 2008 Achieving simplicity Every statement must be implicit: –Guard/retry/exception should be handled by the STM But, for efficiency purpose we can not: –STM should be tuned so that commit throughput is increased How to make an STM flexible ?

17. EPFL - March 7th, 2008 Overview 1.Preliminaries 2.Making STM easy-to-use 3.Making STM flexible 4.Reconciling simplicity and flexibility

18. EPFL - March 7th, 2008 Multi-level Interface NooB Programmer needs Simplicity: Desire of easy-of-use Expert Programmer needs Flexbility: Ability to tune the STM

19. EPFL - March 7th, 2008 Dynamic STM 2 [Herlihy, Luchangco, Moir in OOPSLA 2006] How to use this framework? (NooB programmer) 1.Define your atomic object interface; 2.Pass it to your favorite factory constructor; 3.The factory provides object access; 4.Access the object create/setters/getters.

20. EPFL - March 7th, 2008 Dynamic STM 2 My Interface LinkedListNode Factory Class LinkedListNode My Atomic Code

21. EPFL - March 7th, 2008 What is tunable? What can be made tunable? Contention Manager –Which transaction should abort the other? Escape Mechanisms –Could we provide early-release action? …and so on

22. EPFL - March 7th, 2008 Dynamic STM 2 [Herlihy, Luchangco, Moir, OOPSLA 2006] How to extend this framework? (expert programmer) 1.Define your atomic object interface; 2.Write your own factory and/or contention manager; 3.Pass it to your factory constructor; 4.The factory provides object access; 5.Access the object create/setters/getters.

23. EPFL - March 7th, 2008 Dynamic STM 2 My Interface LinkedListNode Factory Class LinkedListNode My Factory My Atomic Code

24. EPFL - March 7th, 2008 Dynamic STM 2 My Interface LinkedListNode Factory Class LinkedListNode My Factory My Atomic Code My Contention Manager

25. EPFL - March 7th, 2008 Dynamic STM 2 My Interface LinkedListNode Obstruction-free Factory Class LinkedListNode My Atomic Code

26. EPFL - March 7th, 2008 Dynamic STM 2 My Interface LinkedListNode Shadow Factory Class LinkedListNode My Atomic Code

27. EPFL - March 7th, 2008 Dynamic STM 2 To conclude: -Especially-suited for object-based STMs; -Indirection is the general mechanism; -STM changes imply interface change. Can we make it more flexible?

28. EPFL - March 7th, 2008 What is tunable? What can be made tunable? Contention Manager –Which transaction should abort the other? Escape Mechanisms –Could we provide early-release action? Data access granularity –Object-/Field-/Word-based …and so on DSTM2

29. EPFL - March 7th, 2008 Intel STM transactional Java application transactional memory runtime transactional C application StarJIT/ ORP JVM Proton compiler SMP system Simulator (HW support) This slide is taken from a talk of Adam Welc [youTube tYRIg4M5xNM]

30. EPFL - March 7th, 2008 Intel STM Write: Acquire lock on tx-record Logs old value for roll-back in tx-descriptor Record value read in read-set of tx-descriptor Read: Records value read in read-set of tx-descriptor Termination: Validate read-set versions w.r.t. tx-descriptor Empty read-set, write-set, undo-log

31. EPFL - March 7th, 2008 Intel STM To conclude: -Application language independent -Direct access -Eager update Can we make it more flexible?

32. EPFL - March 7th, 2008 Overview 1.Preliminaries 2.Making STM easy-to-use 3.Making STM flexible 4.Reconciling simplicity and flexibility

33. EPFL - March 7th, 2008 Simplicity, Basic Interface interface STMBasicallyUsable { void beginTransaction() void commitTransaction() }

34. EPFL - March 7th, 2008 Simplicity, Basic Interface ApplicationSTM beginTransaction() endTransaction()

35. EPFL - March 7th, 2008 Flexibility, Advanced Interface interface STMCarefullyUsable extends Tunable { void beginTransaction() void commitTransaction() }

36. EPFL - March 7th, 2008 Interfacing STM Application STM beginTransaction() endTransaction() onAbort() onCommit() Abort handler Commit handler resolveConflict() Contention manager store() load() Memory abort() commit()

37. EPFL - March 7th, 2008 Flexibility, Advanced Interface interface STMCarefullyUsable extends Tunable { void beginTransaction() void commitTransaction() }

38. EPFL - March 7th, 2008 What is tunable? What can be made tunable? Contention Manager –Which transaction should abort the other? Escape Mechanisms –Could we provide early-release action? Data access granularity –Object-/Field-/Word-based Eager/Lazy update –should write operations take effect before commit? Direct vs. indirect access –E.g. compare-and-set “pointer to changes” or “lock of changes”? Operation visibility –should read operations conflict with operations of other transactions? …and so on

39. EPFL - March 7th, 2008 What is tunable? What can be made tunable? Contention Manager –Which transaction should abort the other? Escape Mechanisms –Could we provide early-release action? Data access granularity –Object-/Field-/Word-based Eager/Lazy update –should write operations take effect before commit? Direct vs. indirect access –E.g. compare-and-set “pointer to changes” or “lock of changes”? Operation visibility –should read operations conflict with operations of other transactions? …and so on DSTM2

40. EPFL - March 7th, 2008 What is tunable? What can be made tunable? Contention Manager –Which transaction should abort the other? Escape Mechanisms –Could we provide early-release action? Data access granularity –Object-/Field-/Word-based Eager/Lazy update –should write operations take effect before commit? Direct vs. indirect access –E.g. compare-and-set “pointer to changes” or “lock of changes”? Operation visibility –should read operations conflict with operations of other transactions? …and so on DSTM2 Intel STM

41. EPFL - March 7th, 2008 Conclusion Interfaces define the role the STM must play to maximize performance to be easy-to-use Various STM techniques are efficient in different cases: Direct/Indirect access, Access granularity, Contention manager, Operation visibility, Eager/Lazy update… Unifying those techniques in a generic STM: Simplicity: allows the programmer to choose the one he understands Flexibility: allows the programmer to choose the one he needs

42. EPFL - March 7th, 2008 Open questions Which techniques are not compatible? e.g. indirection and eager update How to refine interface to transactions? e.g. one transaction with eager update, another with lazy-update Could we find the interface to unify all STMs?