“Transactional Memory in Practice"
summary
Company product Dynamics runs a homegrown software transactional memory system in production for four years, replacing many mutexes and easing parallel calculations across an 800–900k LOC codebase. The system uses explicit transactional variables, optimistic concurrency with read/write journals, nested transactions merged into parents, and after‑commit callbacks; pitfalls include side‑effect duplication on retries, starvation from fast short transactions, retry deadlocks, and memory‑allocation surprises — solved by validate calls, conflict limits, and a heavy‑handed run‑locked fallback.
AI-written summary · about
chapters (25)
- 0:00Intro
- 1:05Atomics
- 11:57Transactional Variables
- 12:59Optimistic Concurrency
- 14:19Nested Transactions
- 16:33Starting a transaction
- 20:12Transaction Safety
- 22:04Simple Transfer
- 23:01Transfer with notification
- 24:30Waiting for a balance
- 25:59Side-effects
- 29:14NO_ATOMIC
- 29:56Starvation
- 33:41Retry Deadlock
- 34:56Split the transactions
- 39:26Validate
- 42:26Weak Atomicity
- 43:44Invasive
- 45:16No one's heard of it
- 47:53Calculation Structure
- 48:29Performance
- 50:34Hardware Transactional Memory
- 53:38How'd it work out?
- 54:42Open Source?
- 55:44Resources
related talks
01h 01mUnderstanding Hardware Transactional Memory
01h 13mTransactional memory
01h 33mWhy You Should Use Software Transactional Memory
01h 00mWhat did C++ do for Transactional Memory?
14mArchTM: Architecture-Aware, High Performance Transaction for Persistent Memory
15mHTMFS: Strong Consistency Comes for Free with Hardware Transactional Memory...
30mImplementing and Verifying Release-Acquire Transactional Memory in C11
18mThe Semantics of Transactions and Weak Memory in x86, Power, ARM, and C++