Making nested parallel transactions practical using lightweight hardware support

Abstract

Transactional Memory (TM) simplifies parallel programming by supporting parallel tasks that execute in an atomic and isolated way. To achieve the best possible performance, TM must support the nested parallelism available in real-world applications and supported by popular programming models. A few recent papers have proposed support for nested parallelism in software TM (STM) and hardware TM (HTM). However, the proposed designs are still impractical, as they either introduce excessive runtime overheads or require complex hardware structures.This paper presents filter-accelerated, nested TM (FaNTM). We extend a hybrid TM based on hardware signatures to provide practical support for nested parallel transactions. In the FaNTM design, hardware filters provide continuous and nesting-aware conflict detection, which effectively eliminates the excessive overheads of software nested transactions. In contrast to a full HTM approach, FaNTM simplifies hardware by decoupling nested parallel transactions from caches using hardware filters. We also describe subtle correctness and liveness issues that do not exist in the non-nested baseline TM.We quantify the performance of FaNTM using STAMP applications and microbenchmarks that use concurrent data structures. First, we demonstrate that the runtime overhead of FaNTM is small (2.3% on average) when applications use only single-level parallelism. Second, we show that the incremental performance overhead of FaNTM is reasonable when the available parallelism is used in deeper nesting levels. We also demonstrate that nested parallel transactions on FaNTM run significantly faster (e.g., 12.4×) than those on a nested STM. Finally, we show how nested parallelism is used to improve the overall performance of a transactional microbenchmark.

Fractal

“…Prior HTMs have supported composable nested parallel transactions, but they suffer from deadlock and livelock conditions, impose large overheads, and sacrifice most of the benefits of fine-grain parallelism because each nested transaction merges its speculative state with its parent's [5,6]. We compare FRACTAL and parallel nesting HTMs in detail in Sec.…”

“…Most HTMs only support serial execution of nested transactions, forgoing intra-transaction parallelism. A few HTMs support parallel nested transactions [6,62], but they parallelize at the coarsest levels, suffer from subtle deadlock and livelock conditions, and impose large overheads because they merge the speculative state of nested transactions [5,6]. The FRACTAL execution model lets our implementation avoid these problems.…”

Delegation and nesting in best-effort hardware transactional memory

“…As long as one endpoint cannot perform consecutive StTxChannel instructions without intervening acknowledgments, the illusion of atomicity is preserved. 4 …”

“…Moravan et al [34] extended LogTM with (non-parallel) open-nested transactions, and FaNTM [4] accelerated NeSTM via hardware signatures. These techniques all required modifications to the pipeline or coherence protocol.…”

“…Given this definition, TxChannel can be thought of as an atomic register shared between exactly two threads 4. On architectures with relaxed memory consistency, one fence instruction would be required per channel access.…”