Leveraging parallel nesting in transactional memory

Abstract

Exploiting the emerging reality of affordable multi-core architectures goes through providing programmers with simple abstractions that would enable them to easily turn their sequential programs into concurrent ones that expose as much parallelism as possible. While transactional memory promises to make concurrent programming easy to a wide programmer community, current implementations either disallow nested transactions to run in parallel or do not scale to arbitrary parallel nesting depths. This is an important obstacle to the central goal of transactional memory, as programmers can only start parallel threads in restricted parts of their code. This paper addresses the intrinsic difficulty behind the support for parallel nesting in transactional memory, and proposes a novel solution that, to the best of our knowledge, is the first practical solution to meet the lowest theoretical upper bound known for the problem.Using a synthetic workload configured to test parallel transactions on a multi-core machine, a practical implementation of our algorithm yields substantial speed-ups (up to 22x with 33 threads) relatively to serial nesting, and shows that the time to start and commit transactions, as well as to detect conflicts, is independent of nesting depth.

ByteSTM: Virtual Machine-Level Java Software Transactional Memory

“…Each transaction can then access its metadata and its parent's metadata directly from the thread header. For parallel nesting (i.e., each child transaction runs in its own thread) [2,5], a global data structure, where a child can find its parent's metadata, can be added.…”

Making nested parallel transactions practical using lightweight hardware support

“…The number of TMBs in the filter limits the number of transactions that can be mapped on each processor without the need for virtualization. When nesting depth overflows, we currently rely on software solutions such as switching back to a nested STM [3,4,15] or subsuming (i.e., serializing and flattening) nested transactions to avoid increasing hardware complexity. We leave hardware techniques for depth virtualization as future work.…”

“…Based on the proposed model, a few recent papers investigated nested parallelism in STM [2-4, 15, 21]. While compatible with existing multicore chips, this software-only approach may introduce excessive runtime overheads due to the use of complicated data structures [2,4] or the use of an algorithm whose time complexity is proportional to the nesting depth [3], limiting its practicality. Our work differs because FaNTM aims to eliminate substantial overheads of software nested transactions using hardware acceleration.…”

“…While compatible with existing multicore chips, most STM implementations already suffer from excessive runtime overheads of TM barriers even for single-level parallelism [6]. To make the problem worse, supporting nested parallelism solely in software may introduce additional performance overheads due to the use of complicated data structures [2,4] or the use of an algorithm whose time complexity is proportional to the nesting depth [3]. For example, as shown in our performance evaluation, a singlethreaded, transactional version of the red-black tree microbenchmark runs 6.2× slower with single-level transactions and 17.0× slower with nested transactions than a non-transactional, sequential version.…”

Implementing and evaluating nested parallel transactions in software transactional memory

“…A few recent works on nested parallelism in STM have discussed the semantics of nested parallel transactions and provided prototype implementations [2,4,18,22]. However, the following questions still require further investigations.…”