Results 1 -
6 of
6
Sandboxing Transactional Memory ∗
"... In a transactional memory (TM) system, conflict detection ensures that transactions never commit unless they can be serialized. Validation further ensures that a doomed transaction (one that has seen an inconsistent view of memory) discovers its status and aborts before its inconsistency has a chanc ..."
Abstract
-
Cited by 11 (4 self)
- Add to MetaCart
(Show Context)
In a transactional memory (TM) system, conflict detection ensures that transactions never commit unless they can be serialized. Validation further ensures that a doomed transaction (one that has seen an inconsistent view of memory) discovers its status and aborts before its inconsistency has a chance to cause erroneous, externally visible behavior. In an opaque TM system, post-validation of reads ensures that the view of memory is always consistent. In a sandboxed TM system, pre-validation of potentially dangerous operations ensures that inconsistency is harmless. Sandboxing is straightforward in managed languages, but its feasibility for unmanaged languages has been questioned and remains an open problem. In this paper we show that it is both possible and practical to implement sandboxing for C and C++ TM systems, with overheads (including wasted work) no worse than those of opaque implementations. Specifically, we present a software TM infrastructure using LLVM, the Dresden TM Compiler, and a novel sandboxing runtime, and describe its performance on a variety of benchmarks. Systems such as ours will, we believe, enable the development of new and faster TM algorithms (in both hardware and software) that depend on sandboxing for correctness—e.g. in conjunction with asynchronous (out-of-band) validation. 1.
STM 2: A Parallel STM for High Performance Simultaneous Multithreading Systems
"... Abstract—Extracting high performance from modern chip multithreading (CMT) processors is a complex task, especially for large CMT systems. Programmers must efficiently parallelize performance-critical software while avoiding deadlocks and race conditions. Transactional memory (TM) is a promising pro ..."
Abstract
-
Cited by 7 (3 self)
- Add to MetaCart
(Show Context)
Abstract—Extracting high performance from modern chip multithreading (CMT) processors is a complex task, especially for large CMT systems. Programmers must efficiently parallelize performance-critical software while avoiding deadlocks and race conditions. Transactional memory (TM) is a promising programming model that allows programmers to focus on parallelism rather than maintaining correctness and avoiding deadlock. Software-only implementations (STMs) are especially compelling because they run on commodity hardware, therefore providing high portability. Unfortunately, STM systems usually suffer from high overheads, which may limit their usage especially at scale. In this paper we present STM 2, a novel parallel STM designed for high performance, aggressive multithreading systems. STM 2 significantly lowers runtime overhead by offloading read-set validation, bookkeeping and conflict detection to auxiliary threads running on sibling hardware threads. Auxiliary threads perform STM operations in parallel with their paired application threads and absorb STM overhead, significantly improving performance. We exploit the fact that, on modern multi-core processors, sets of cores can share L1 or L2 caches. This lets us achieve closer coupling between the application thread and the auxiliary thread (when compared with a traditional multi-processor systems). Our results, performed on an IBM POWER7 machine, a state-of-theart, aggressive multi-threaded system, show that our approach outperforms several well-known STM implementations. In particular, STM 2 shows speedups between 1.8x and 5.2x over the tested STM systems, on average, with peaks up to 12.8x. I.
Transactional Semantics with Zombies
- In: Proc. WTTM’14 (Jul 2014
"... Different formal models of transactional memory are re-quired at different levels of the system stack. This paper focuses on the run-time level, where the semantics of in-dividual operations (start, read, write, try-commit) govern the interactions between the compiler and the TM sys-tem. For sandbox ..."
Abstract
-
Cited by 2 (0 self)
- Add to MetaCart
(Show Context)
Different formal models of transactional memory are re-quired at different levels of the system stack. This paper focuses on the run-time level, where the semantics of in-dividual operations (start, read, write, try-commit) govern the interactions between the compiler and the TM sys-tem. For sandboxing TM systems, which allow a doomed transaction (a “zombie”) to continue for some time be-yond an inconsistent read, run-time–level semantics can-not be captured by opacity as currently defined: we need a formal model of zombie execution. 1
A Case of System-level Hardware/Software Co-design and Co-verification of a Commodity Multi-Processor System with Custom Hardware
"... This paper presents an interesting system-level co-design and co-verification case study for a non-trivial design where multiple high-performing x86 processors and custom hardware were connected through a coherent interconnection fabric. In functional verification of such a system, we used a process ..."
Abstract
-
Cited by 1 (0 self)
- Add to MetaCart
(Show Context)
This paper presents an interesting system-level co-design and co-verification case study for a non-trivial design where multiple high-performing x86 processors and custom hardware were connected through a coherent interconnection fabric. In functional verification of such a system, we used a processor bus functional model (BFM) to combine native software execution with a cycle-accurate interconnect simulator and an HDL simulator. However, we found that significant extensions need to be made to the conventional BFM methodology in order to capture various data-race cases in simulation, which eventually happen in modern multiprocessor systems. Especially essential were faithful implementations of the memory consistency model and cache coherence protocol, as well as timing randomization. We demonstrate how such a co-simulation environment can be constructed from existing tools and software. Lessons from our study can similarly be applied to design and verification of other tightly-coupled systems.
Sandboxing Transactional Memory ∗
"... Correct transactional memory systems (TMs) must address the possibility that a speculative transaction may read mutually inconsistent values from memory and then perform an operation that violates the underlying language semantics. TMs for managed languages can leverage type safety, just-intime comp ..."
Abstract
- Add to MetaCart
(Show Context)
Correct transactional memory systems (TMs) must address the possibility that a speculative transaction may read mutually inconsistent values from memory and then perform an operation that violates the underlying language semantics. TMs for managed languages can leverage type safety, just-intime compilation, and fully monitored exceptions to sandbox transactions, isolating the rest of the system from damaging effects of inconsistent speculation. In contrast, TMs for unmanaged languages that lack these properties typically avoid erroneous behavior by validating a transaction’s view of memory incrementally after each read operation. Recent results suggest that performing validation out-ofband can increase performance by factors of 1.7 × to 5.2× over incremental validation, but allowing a transaction’s main computation to progress in parallel with validation introduces periods in which inconsistent speculative execution may violate language semantics. Without sandboxing—which some authors have suggested is not possible in unmanaged languages—programmers must manually annotate transactions with validation barriers whenever inconsistency might lead to semantic violations, an untenable task. In this work we demonstrate that sandboxing for out-ofband validation is, in fact, possible in unmanaged languages. Our implementation integrates signal interposition, periodic validation, and a mix of static and dynamic instrumentation into a system comprising the LLVM-based Dresden TM compiler and the RSTM runtime. We show that these mechanisms introduce negligible overhead, thus extending the results of out-of-band validation to POSIX programs without requiring manual annotation. Furthermore, we establish sandboxing as a technique that can complement, or replace, incremental validation in any TM that keep speculatively written values in a private buffer.
TMbox: A Flexible and Reconfigurable 16-core Hybrid Transactional Memory System
"... In this paper we present the design and implemen-tation of TMbox: An MPSoC built to explore trade-offs in multicore design space and to evaluate parallel programming proposals such as Transactional Memory (TM). Our flexible system, comprised of MIPS R3000-compatible cores is easily modifiable to stu ..."
Abstract
- Add to MetaCart
(Show Context)
In this paper we present the design and implemen-tation of TMbox: An MPSoC built to explore trade-offs in multicore design space and to evaluate parallel programming proposals such as Transactional Memory (TM). Our flexible system, comprised of MIPS R3000-compatible cores is easily modifiable to study different architecture, library and operating system extensions. For this paper we evaluate a 16-core Hybrid Transac-tional Memory implementation based on the TinySTM-ASF proposal on a Virtex-5 FPGA and we accelerate three benchmarks written to investigate TM. 1.
