1 / 81

Sweet Sixteen: How well is Transactional Memory Aging?

Sweet Sixteen: How well is Transactional Memory Aging? . Maurice Herlihy Brown University. Remember 1993?. Citation Count. TM Today. 93,300. Second Opinion. 2,210,000. Third Opinion. zero. Language Support. Clojure. Language Support. Clojure. Scala. Language Support. Haskell.

jonah
Télécharger la présentation

Sweet Sixteen: How well is Transactional Memory Aging?

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. Sweet Sixteen: How well is Transactional Memory Aging? Maurice Herlihy Brown University

  2. Remember 1993? Damon June 2009

  3. Citation Count Damon June 2009

  4. TM Today 93,300 Damon June 2009

  5. Second Opinion 2,210,000 Damon June 2009

  6. Third Opinion zero Damon June 2009

  7. Language Support Clojure Damon June 2009

  8. Language Support Clojure Scala Damon June 2009

  9. Language Support Haskell Clojure Scala Damon June 2009

  10. Language Support Perl Haskell Clojure Scala Damon June 2009

  11. Language Support Phython Perl Haskell Clojure Scala Damon June 2009

  12. Language Support Phython Perl Haskell CaML Clojure Scala Damon June 2009

  13. Language Support Phython Perl Java Haskell CaML Clojure Scala Damon June 2009

  14. Language Support Phython Perl Java Haskell C++ CaML Clojure Scala Damon June 2009

  15. Hatin’ on TM STM is too inefficient Damon June 2009

  16. Hatin’ on TM Requires radical change in programming style Damon June 2009

  17. Hatin’ on TM Erlang-style shared nothing only true path to salvation Damon June 2009

  18. Hatin’ on TM There is nothing wrong with what we do today. Damon June 2009

  19. Gartner Hype Cycle Hat tip: Jeremy Kemp Damon June 2009

  20. Outline • What and why • Hardware TM • Software TM • Lock Elision • Conversion • User studies • Energy Damon June 2009

  21. What is TM? • Hardware (HTM) Damon June 2009

  22. What is TM? • Hardware (HTM) • Software (STM) atomic { node.next = succ; node.prev = pred; succ.pred = node; pred.next = node; } Damon June 2009

  23. What is TM? • Hardware (HTM) • Software (STM) • Lock Elision synchronized { node.next = succ; node.prev = pred; succ.pred = node; pred.next = node; } Damon June 2009

  24. Why TM? • Better lock-free data structures? a d b c Damon June 2009

  25. Why TM? • Better lock-free data structures? • Better software engineering? Damon June 2009

  26. Why TM? • Better lock-free data structures? • Better software engineering? • Better scalability? Damon June 2009

  27. Why TM? • Better lock-free data structures? • Better software engineering? • Better scalability? • Better power? Damon June 2009

  28. Outline • What and why • Hardware TM • Software TM • Lock Elision • Conversion • User studies • Energy Damon June 2009

  29. HTM Original proposal Damon June 2009

  30. HTM Stanford TCC Damon June 2009

  31. HTM Wisconsin LogTM Damon June 2009

  32. HTM Sun “Rock” Damon June 2009

  33. HTM AMD Advanced Synchronization Facility Damon June 2009

  34. HTM Strengths & Weaknesses • Ideal for lock-free data structures Damon June 2009

  35. HTM Strengths & Weaknesses • Ideal for lock-free data structures • Practical proposals have limits on • Transaction size and length • Bounded HW resources • Guarantees vs best-effort Damon June 2009

  36. HTM Strengths & Weaknesses • Ideal for lock-free data structures • Practical proposals have limits on • Transaction size and length • Bounded HW resources • Guarantees vs best-effort • On fail • Diagnostics essential • Retry in software? Damon June 2009

  37. Composition Locks don’t compose, transactions do. Composition necessary for Software Engineering. But practical HTM doesn’treallysupport composition! Why we need STM Damon June 2009

  38. Outline • What and why • Hardware TM • Software TM • Lock Elision • Conversion • User studies • Energy atomic { node.next = succ; node.prev = pred; succ.pred = node; pred.next = node; } Damon June 2009

  39. STM • Code appears to execute atomically atomic { node.next = succ; node.prev = pred; succ.pred = node; pred.next = node; } Damon June 2009

  40. STM • Code appears to execute atomically • Typically executed speculatively atomic { node.next = succ; node.prev = pred; succ.pred = node; pred.next = node; } Damon June 2009

  41. Some I/O revocable Provide transaction-safe libraries Undoable file system/DB calls Some not Dispensing cash Firing missile I/O & System Calls? Damon June 2009

  42. How do transactional & non-transactional threads synchronize? Easy in HTM Not in STM Strong vs Weak Isolation Damon June 2009

  43. Transactions act as if they acquire SGL Good: Intuitively appealing Bad: What about aborted transactions? Conditional synchronization? Single Global Lock Semantics? Damon June 2009

  44. Outline • What and why • Hardware TM • Software TM • Lock Elision • Conversion • User studies • Energy lock(x) { node.next = succ; node.prev = pred; succ.pred = node; pred.next = node; } Damon June 2009

  45. Lock Elision Transparently replace critical sections with transactions Damon June 2009

  46. Lock Elision • Execute critical section speculatively Synchronize on data, not locks lock(x) { node.next = succ; node.prev = pred; succ.pred = node; pred.next = node; } Fall back to locking on repeated FAIL Damon June 2009

  47. Benefits • Transparent • No need to retrain programmers Damon June 2009

  48. Benefits • Transparent • No need to retrain programmers • Works on much legacy code • Not all, see Azul report below Damon June 2009

  49. Benefits • Transparent • No need to retrain programmers • Works on much legacy code • Not all • Ideal for managed run-times Damon June 2009

  50. Applied Lock Elision Lock Elision for contended Java synchronized blocks Good on some, modest on many, bad on few Gratuitous conflicts limit gains Rewriting helps, but tedious Damon June 2009

More Related