Understanding Hardware Transactional Memory
summary
Hardware transactional memory becomes a commodity on Intel servers (Skylake, Broadwell, Haswell‑E, post‑March 2016) and gets used by JVMs (Zing; HotSpot via a flag) to perform speculative lock elision, letting synchronized blocks run concurrently unless data conflicts force aborts. Transactions track all accessed cache lines so they succeed only if they fit without eviction — practical limits are around L1 (~32KB) with associativity quirks that can fail with as few as nine conflicted addresses (cache-capacity limits). Microbenchmarks and customer data show typical gains from modest to 2x or ~50% better concurrency for coarse‑locked structures after simple changes (striped counters, cached size); it works but requires per‑lock heuristics to avoid regressions.
AI-written summary · about
chapters (14)
- 0:00Introduction to HTM
- 1:05Background and context
- 6:07HTM in modern CPUs
- 8:17What is HTM?
- 10:59HTM and cache coherence
- 20:26CPU state and transactions
- 22:18Speculative lock elision
- 26:23Scaling and Amdahl's Law
- 30:24Lock vs data contention
- 35:35JVM transactional support
- 40:37Benchmarks and heuristics
- 43:10Coding for HTM benefits
- 49:48Future of HTM
- 50:53Questions and answers
related talks
01h 13mTransactional memory
01h 03m“Transactional Memory in Practice"
01h 00mWhat did C++ do for Transactional Memory?
01h 33mWhy You Should Use Software Transactional Memory
15mHTMFS: Strong Consistency Comes for Free with Hardware Transactional Memory...
14mArchTM: Architecture-Aware, High Performance Transaction for Persistent Memory
12mSPHT: Scalable Persistent Hardware Transactions
18mThe Semantics of Transactions and Weak Memory in x86, Power, ARM, and C++