1 / 20

Does Hardware Transactional Memory Change Everything?

Does Hardware Transactional Memory Change Everything?. Maurice Herlihy Computer Science Dept Brown University. Not important:. The details. Important. Irrevocable change. How to think about Synchronization. Amdal’s Law. Poor synchronization ruins everything.

brent
Download Presentation

Does Hardware Transactional Memory Change Everything?

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. Does Hardware Transactional Memory Change Everything? Maurice Herlihy Computer Science Dept Brown University

  2. Not important: The details. Important Irrevocable change

  3. How to think about Synchronization

  4. Amdal’s Law Poor synchronization ruins everything

  5. New synchronization architectures will have a pervasive effect … on the entire stack. Not just improving … STM, lock elision, etc.. But rethinking … algorithms models … theory of data structures & libraries

  6. b a c Hand-over-Hand locking

  7. b a c Hand-over-Hand locking

  8. b a c Hand-over-Hand locking

  9. b a c Hand-over-Hand locking

  10. b a c Hand-over-Hand locking Arguably better than a coarse-grained lock … but too many lock acquisitions … & no overtaking.

  11. b a c Transactional HoHlocking read read Transaction

  12. b a c Transactional HoHlocking HW Transactions play well with locks …. Consistent snapshot …. Followed by lock acquisition … is something new!

  13. Lock Elision …. (That is, transparently replacing locks with speculative transactions) Is a point solution … Because it affects only one lock/ code block. What about using speculation for multiple locks?

  14. Legacy code …. Dangerous to modify locking policies … Poorly understood. Speculatively preacquire sequence of locks? Retrofit (more) deterministic execution … Reduce deadlocks, delays? Performance implications? Theorem? Such transformations preserve correctness

  15. Modern locks themselves …. Very complex data structures Abortable Read-Write NUMA Biased … Conjecture: Perhaps we can drain the swamp …. Same goes for: Barriers Work-stealing Fork-join exchangers Anything done by java.util.concur

  16. RCU (read-copy-update) Readers proceed without locks … But writers follow awkward protocol …. ``While RCU is widely adopted in the Linux kernel, it has not been applied to the kernel's address space structures because of two significant challenges: the address space structures obey complex invariants that make RCU's restrictions on readers and writers onerous, and fully applying RCU to the address space structures requires an RCU-compatible concurrent balanced tree, for which no simple solutions exist.'' [Clements et al. 2012] Support both light-weight reads & non-trivial updates?

  17. Memory Management? Malloc/free vs lock-free data structures? Reference counts? Hazard pointers? RCU? Transactions can transform & improve these techniques?

  18. Granularity?

  19. Progress guarantees? (weasel words)

  20. Modern synchronization architectures require … A new stack …. Data structures Algorithms Synchronization structures OS, VM functions A new theory …. progress complexity transformations

More Related