1 / 42

Interfacing Software Transactional Memory Simplicity vs. Flexibility

Interfacing Software Transactional Memory Simplicity vs. Flexibility. Vincent Gramoli. Multi-core Motivations. Transistor size allows multi-core. Multi-core Motivations. Transistor size allows multi-core Processor speed is power-consuming. Multi-core Motivations.

minor
Download Presentation

Interfacing Software Transactional Memory Simplicity vs. Flexibility

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. Interfacing Software Transactional Memory Simplicity vs. Flexibility Vincent Gramoli

  2. Multi-core Motivations • Transistor size allows multi-core

  3. Multi-core Motivations • Transistor size allows multi-core • Processor speed is power-consuming

  4. Multi-core Motivations • Transistor size allows multi-core • Processor speed is power-consuming • Limiting computation speed

  5. Software Transactional Memory 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. Goal Making STM simple and flexible! • Making STM simple: Any programmer should be able to use it • Making STM flexible: STM should be efficient in any situations

  7. Overview • Preliminaries • Making STM easy-to-use • Making STM flexible • Reconciling simplicity and flexibility

  8. What is an interface? “The interactions of an object with the outside world.” [java.sun.com]

  9. Interfacing STM Application STM beginTransaction() endTransaction()

  10. Interfacing STM Application STM beginTransaction() Abort handler onAbort() endTransaction() Commit handler onCommit()

  11. Interfacing STM • Is the abort handler part of the STM? • Is the commit handler part of the Application? • What should be defined explicitly?

  12. Overview • Preliminaries • Making STM easy-to-use • Making STM flexible • Reconciling simplicity and flexibility

  13. 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. 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. 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. 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. Overview • Preliminaries • Making STM easy-to-use • Making STM flexible • Reconciling simplicity and flexibility

  18. Multi-level Interface NooB Programmer needs Simplicity: Desire of easy-of-use Expert Programmer needs Flexbility: Ability to tune the STM

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

  20. Dynamic STM 2 My Interface LinkedListNode My Atomic Code Factory Class LinkedListNode

  21. 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. Dynamic STM 2 [Herlihy, Luchangco, Moir, OOPSLA 2006] How to extend this framework? (expert programmer) • Define your atomic object interface; • Write your own factory and/or contention manager; • Pass it to your factory constructor; • The factory provides object access; • Access the object create/setters/getters.

  23. Dynamic STM 2 My Interface LinkedListNode My Atomic Code Factory My Factory Class LinkedListNode

  24. Dynamic STM 2 My Interface LinkedListNode My Atomic Code Factory My Factory My Contention Manager Class LinkedListNode

  25. Dynamic STM 2 My Interface LinkedListNode My Atomic Code Obstruction-free Factory Class LinkedListNode

  26. Dynamic STM 2 My Interface LinkedListNode My Atomic Code Shadow Factory Class LinkedListNode

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

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

  30. 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. Intel STM To conclude: • Application language independent • Direct access • Eager update Can we make it more flexible?

  32. Overview • Preliminaries • Making STM easy-to-use • Making STM flexible • Reconciling simplicity and flexibility

  33. Simplicity, Basic Interface interface STMBasicallyUsable { void beginTransaction() void commitTransaction() }

  34. Simplicity, Basic Interface Application STM beginTransaction() endTransaction()

  35. Flexibility, Advanced Interface interface STMCarefullyUsable extends Tunable { void beginTransaction() void commitTransaction() }

  36. Interfacing STM Application STM Contention manager beginTransaction() resolveConflict() abort() Abort handler Memory onAbort() store() load() endTransaction() commit() Commit handler onCommit()

  37. Flexibility, Advanced Interface interface STMCarefullyUsable extends Tunable { void beginTransaction() void commitTransaction() }

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

  40. 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 DSTM2 Intel STM

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

More Related