17.1 Transactional Memory
Keywords: perfbook_html

#
17.1 Transactional Memory

The idea of using transactions outside of databases goes back many decades [Lom77], with the key difference between database and non-database transactions being that non-database transactions drop the ``D'' in the ``ACID'' properties defining database transactions. The idea of supporting memory-based transactions, or ``transactional memory'' (TM), in hardware is more recent [HM93], but unfortunately, support for such transactions in commodity hardware was not immediately forthcoming, despite other somewhat similar proposals being put forward [SSHT93]. Not long after, Shavit and Touitou proposed a software-only implementation of transactional memory (STM) that was capable of running on commodity hardware, give or take memory-ordering issues. This proposal languished for many years, perhaps due to the fact that the research community's attention was absorbed by non-blocking synchronization (see Section ).

But by the turn of the century, TM started receiving more attention [MT01,RG01], and by the middle of the decade, the level of interest can only be termed ``incandescent'' [Her05,Gro07], despite a few voices of caution [BLM05,MMW07].

The basic idea behind TM is to execute a section of code atomically, so that other threads see no intermediate state. As such, the semantics of TM could be implemented by simply replacing each transaction with a recursively acquirable global lock acquisition and release, albeit with abysmal performance and scalability. Much of the complexity inherent in TM implementations, whether hardware or software, is efficiently detecting when concurrent transactions can safely run in parallel. Because this detection is done dynamically, conflicting transactions can be aborted or ``rolled back'', and in some implementations, this failure mode is visible to the programmer.

Because transaction roll-back is increasingly unlikely as transaction size decreases, TM might become quite attractive for small memory-based operations, such as linked-list manipulations used for stacks, queues, hash tables, and search trees. However, it is currently much more difficult to make the case for large transactions, particularly those containing non-memory operations such as I/O and process creation. The following sections look at current challenges to the grand vision of ``Transactional Memory Everywhere'' [McK09b].

Subsections

- 17.1.1 I/O Operations
- 17.1.2 RPC Operations
- 17.1.3 Memory-Mapping Operations
- 17.1.4 Multithreaded Transactions
- 17.1.5 Extra-Transactional Accesses
- 17.1.6 Time Delays
- 17.1.7 Locking
- 17.1.8 Reader-Writer Locking
- 17.1.9 Persistence
- 17.1.10 Dynamic Linking and Loading
- 17.1.11 Debugging
- 17.1.12 The exec() System Call
- 17.1.13 RCU
- 17.1.14 Discussion