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. FlatLogTM 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.

Automated dynamic detection of busy–wait synchronizations

“…HTM system. For our TM experiments, we consider an HTM system that uses an EE policy similar to the logT M system [25]. We used emulation in Pin to estimate the overhead of transactional memory.…”

“…Let us assume that processor 1 reaches the while loop first where it spins until the value of f lag becomes 1, which is set subsequently by processor 2. Furthermore, we assume that the HTM system follows eager conflict detection, eager version management, and requester loses policy similar to the one followed in the logTM system [25]. Now let us analyze the sequence of events in the execution.…”

TMbarrier: Speculative Barriers Using Hardware Transactional Memory

“…The scheme outlined so far considers only a single speculative transaction per thread, because no transaction is allowed to commit until glOrder is updated to match speculative epochs. To improve the speculative execution efficiency, a maximum of specMax transactions per thread are allowed to execute after a tmbarrier by leveraging nested transactions [19]. The TM system will open an outer transaction after the tmbarrier, so subsequent transactions are started as inner nested ones up to a maximum of specMax.…”

“…Transaction start is similar to algorithm 1. However, in the case of an abort (lines [12][13][14][15][16][17][18][19], if the thread is speculative it is prevented to switch to sw-xact state. Instead, it decrements specMax and restarts the tx.retries counter.…”

“…Nested transactions in POWER8 HTM are handled by flattening inner transactions into the corresponding outer one. This feature has two disadvantages compared to other more advanced techniques [19]. First, a conflict in an inner transaction triggers the abort of all the transactions enclosed by the same outer transaction.…”