Supporting nested transactional memory in logTM

Abstract

Nested transactional memory (TM) facilitates software composition by letting one module invoke another without either knowing whether the other uses transactions. Closed nested transactions extend isolation of an inner transaction until the toplevel transaction commits. Implementations may flatten nested transactions into the top-level one, resulting in a complete abort on conflict, or allow partial abort of inner transactions. Open nested transactions allow a committing inner transaction to immediately release isolation, which increases parallelism and expressiveness at the cost of both software and hardware complexity.This paper extends the recently-proposed flat Log-based Transactional Memory (LogTM) with nested transactions. Flat LogTM saves pre-transaction values in a log, detects conflicts with read (R) and write (W) bits per cache block, and, on abort, invokes a software handler to unroll the log. Nested LogTM supports nesting by segmenting the log into a stack of activation records and modestly replicating R/W bits. To facilitate composition with nontransactional code, such as language runtime and operating system services, we propose escape actions that allow trusted code to run outside the confines of the transactional memory system.

Transactional boosting

“…It could encompass STMs based on nested transactions using techniques similar to those employed by LogTM [21]. Transactions could be extended to encompass multiple threads, using abstract locks for transactional synchronization, and relying on the base object for thread-level synchronization.…”

“…This approach has been investigated in hardware [14,21], in software [8,9,13,27], and in schemes that mix hardware and software [6,25]. Existing STMs synchronized via read/write conflicts, which may cause benign conflicts (see Harris et al [10]).…”

“…Moravan et al [21] and Zilles and Baugh [31] observe that constructs similar to open nested transactions can be used to allow transactions to execute non-transactional code, such as system calls.…”

Thread Synchronization: From Mutual Exclusion to Transactional Memory

“…Moravan et al proposed to extend Log-TM with nesting support [46]. The design supports closed nesting with partial aborts by extending the read/write bits.…”

Split hardware transactions

“…true open and closed nesting with nested retry. There are proposals that support true closed nesting [23] and provide assistance to software for concurrency control with retry [4], but the trend is to focus on mechanisms that shift policy and scheduling decisions to software.…”