Nested parallelism in transactional memory

Agrawal, Kunal; Fineman, Jeremy T.; Sukha, Jim

doi:10.1145/1345206.1345232

Cited by 42 publications

(52 citation statements)

References 18 publications

Supporting

Mentioning

Contrasting

Order By: Relevance

“…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.…”

Section: Limitationsmentioning

confidence: 99%

ByteSTM: Virtual Machine-Level Java Software Transactional Memory

Mohamedin

Ravindran

Palmieri

2013

Lecture Notes in Computer Science

View full text Add to dashboard Cite

We present ByteSTM, a virtual machine-level Java STM implementation that is built by extending the Jikes RVM. ByteSTM implements two STM algorithms, TL2 and RingSTM. We modify Jikes RVM's Optimizing compiler to transparently support implicit transactions. Being implemented at the VM-level, it accesses memory directly and handles memory uniformly, and avoids Java garbage collection by manually managing memory for transactional metadata. Our experimental studies reveal throughput improvement over other non-VM STMs in the range of 7%-66% on micro-benchmarks and 7%-76% on macro-benchmarks.

show abstract

Section: Limitationsmentioning

confidence: 99%

ByteSTM: Virtual Machine-Level Java Software Transactional Memory

Mohamedin

Ravindran

Palmieri

2013

Lecture Notes in Computer Science

View full text Add to dashboard Cite

show abstract

“…Interaction between threads can occur within lock-based critical sections but not within transactions. (Concurrency within transactions [6] is not considered here. )…”

Section: Reference Implementationsmentioning

confidence: 99%

Transactions as the Foundation of a Memory Consistency Model

Dalessandro

Scott

Spear

2010

Lecture Notes in Computer Science

View full text Add to dashboard Cite

We argue for transactions as the synchronization primitive of an ordering-based memory consistency model. Rather than define transactions in terms of locks, our model defines locks, conditions, and atomic/volatile variables in terms of transactions. A traditional critical section, in particular, is a region of code, bracketed by transactions, in which certain data have been privatized. Our memory model, originally published at OPODIS'08, is based on the database notion of strict serializability (SS). In an explicit analogy to the DRF 0 of Adve and Hill, we demonstrate that SS provides the appearance of transactional sequential consistency (TSC) for programs that are transactional data-race free (TDRF).We argue against relaxation of the total order on transactions, but show that selective relaxation of the relationship between program order and transaction order (selective strict serializability-SSS) can allow the implementation of transaction-based locks to be as efficient as conventional locks. We also show that condition synchronization (in the form of the transactional retry primitive) can be accommodated in our model without explicit mention of speculation, opacity, or aborted transactions. Finally, we compare SS and SSS to the notion of strong isolation (SI), arguing that SI is neither sufficient for TSC nor necessary in programs that are TDRF.

show abstract

“…We refer readers to [2,14] for additional discussions. Definitions and concepts: Each transaction is assigned a transaction ID (TID), a positive integer.…”

Section: Semantics Of Concurrent Nestingmentioning

confidence: 99%

“…One of the critical performance bottlenecks of NesTM is repeated read-set validation, where the same memory object must be repeatedly validated across different nesting levels [3]. Since this performance overhead increases linearly with the nesting depth, it limits the applications for which NesTM can improve performance [2,3]. Furthermore, NesTM barriers are more complicated, impacting performance even for toplevel transactions.…”

Section: Nestmmentioning

confidence: 99%

“…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.…”

Section: Introductionmentioning

confidence: 99%

See 1 more Smart Citation

Making nested parallel transactions practical using lightweight hardware support

Baek

Bronson

Kozyrakis

et al. 2010

Proceedings of the 24th ACM International Conference on Supercomputing

View full text Add to dashboard Cite

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.

show abstract

Nested parallelism in transactional memory

Cited by 42 publications

References 18 publications

ByteSTM: Virtual Machine-Level Java Software Transactional Memory

ByteSTM: Virtual Machine-Level Java Software Transactional Memory

Transactions as the Foundation of a Memory Consistency Model

Making nested parallel transactions practical using lightweight hardware support

Contact Info

Product

Resources

About