Herlihy and Moss: Transactional Memory as Hardware-Supported Atomicity
Maurice Herlihy and J. Eliot Moss proposed transactional memory in 1993 as an architectural way to group multiple shared-memory operations into an atomic transaction without conventional locks.
Locks made atomicity possible but exposed difficult failure modes
Shared-memory programs often need to update several locations as one logical operation. Mutexes can protect such a region, but lock-based code introduces familiar hazards including deadlock, priority inversion, convoying and poor composability.
Maurice Herlihy and J. Eliot Moss asked whether hardware could support a different abstraction: execute a group of reads and writes speculatively, then commit them atomically if no conflicting activity invalidated the transaction.
The analogy came from database transactions
Database systems already grouped many operations into atomic transactions with commit and abort. Transactional memory imported that conceptual structure into fine-grained access to ordinary shared memory.
The 1993 paper introduced transactional memory as an architectural mechanism
Herlihy and Moss’s ISCA paper introduced transactional memory as hardware support for lock-free data structures. Their design allowed a processor to perform a sequence of memory accesses as a transaction and either commit the whole set atomically or abort when conflicts occurred.[1]
The proposal aimed to make customized multiword read-modify-write operations easier and more efficient than building every nonblocking object from a small primitive such as compare-and-swap.
Speculation postpones the visibility of writes
A transaction can execute tentatively while the system tracks its read and write set. Only a successful commit makes the writes visible as one atomic state change.
Conflict detection replaced explicit lock ownership
Instead of acquiring a lock before entering a critical section, the system observes whether concurrent transactions access the same data in incompatible ways. A conflict can cause one transaction to abort and retry.
This changes the programming model from pessimistic exclusion to optimistic speculation. Parallelism is allowed when transactions do not actually conflict, even if their code regions would have been protected by the same coarse lock.
Software transactional memory separated the abstraction from special hardware
Nir Shavit and Dan Touitou’s 1995 work introduced software transactional memory, showing that transactional semantics could be implemented in software using existing synchronization primitives.[2]
STM broadened the research agenda. Transactions became a programming-language and runtime abstraction rather than only a proposed processor feature, opening questions about contention managers, metadata, validation and compiler instrumentation.
Hardware and software transactional memory optimize different layers
Hardware can track conflicts quickly but has finite cache and bookkeeping capacity. Software can support larger or more flexible transactions but pays instrumentation overhead. Hybrid systems try to combine both.
Programming-language research explored whether transactions compose better than locks
Tim Harris and Keir Fraser’s work on language-supported lightweight transactions demonstrated how atomic blocks could simplify concurrent programming by letting the runtime manage conflicts and retries.[3]
One attraction is composability. Two operations implemented with transactions can often be combined inside a larger transaction, whereas composing independently locked abstractions may introduce lock ordering problems or expose internal synchronization policy.
Transactional memory still had to confront irreversible actions
Memory writes can be rolled back, but external effects such as file I/O, network sends and device operations may not be reversible. Transactions also interact with system calls, exceptions, page faults and long-running computations.
These limitations made transactional memory most natural for carefully bounded shared-memory critical sections rather than arbitrary application code. The abstraction is powerful, but its atomicity boundary must match operations the runtime can actually control.
Capacity aborts are an architectural constraint
Hardware transactions usually track speculative state in caches or finite internal structures. A transaction that touches too much data can abort even when there is no logical conflict, so software needs a fallback path.
Intel TSX brought hardware transactions into commodity processors
Intel introduced Transactional Synchronization Extensions as a hardware feature for speculative lock elision and transactional execution on selected processors. Intel’s optimization documentation explains the Restricted Transactional Memory and Hardware Lock Elision interfaces and their abort behavior.[4]
The deployment history also showed the engineering difficulty of the feature: implementations, errata and product support varied across generations. Research elegance does not remove the verification burden of speculative hardware.
Why transactional memory remains historically important
Transactional memory reframed synchronization as a speculative atomicity problem rather than solely a lock-management problem. The 1993 hardware proposal, software transactional memory, language-level atomic blocks and commercial hardware all explored the same central idea from different layers.[1][2][3][4]
Even where transactions are not the dominant synchronization primitive, the research changed how computer scientists think about composability and optimistic concurrency. The University of Wisconsin’s transactional-memory bibliography documents the breadth of the field that followed.[5]
Works Cited
- 01
- 02
- 03
- 04
- 05University of Wisconsin — Transactional Memory Bibliography research.cs.wisc.edu
CodeHistory is a living archive. Citations document the evidence used for this edition; later evidence may refine the account.
Submit a research lead