Using Hardware Memory Protection to Build a High-Performance, Strongly-Atomic Hybrid Transactional Memory

Baugh, Lee W.; Neelakantam, Naveen; Zilles, Craig

doi:10.1145/1394608.1382132

Cited by 35 publications

(32 citation statements)

References 33 publications

Supporting

Mentioning

Contrasting

Order By: Relevance

“…Pacman is also related to hardware-based mechanisms for finegrain memory protection, such as UFO [1] and iWatcher [33]. In UFO, each memory line has some bits that specify protection information.…”

Section: Other Related Workmentioning

confidence: 99%

Pacman: Tolerating asymmetric data races with unintrusive hardware

Otsuki

Nogueira

et al. 2012

IEEE International Symposium on High-Performance Comp Architecture

View full text Add to dashboard Cite

Data races are a major contributor to parallel software unreliability. A type of race that is both common and typically harmful is the Asymmetric data race. It occurs when at least one of the racing threads is inside a critical section. Current proposals that target them are software-based. They slow down execution and require significant compiler, operating system (OS), or application changes.This paper proposes the first scheme to tolerate asymmetric data races in production runs with negligible execution overhead. The scheme, called Pacman, exploits cache coherence hardware to temporarily protect the variables that a thread accesses in a critical section from other threads' requests. Unlike previous schemes, Pacman induces negligible slowdown, needs no support from the compiler or (in the baseline design) from the OS, and requires no application source code changes. In addition, its hardware is relatively unintrusive. We test Pacman with the SPLASH-2, PARSEC, Sphinx3, and Apache codes, and discover two unreported asymmetric data races.

show abstract

Section: Other Related Workmentioning

confidence: 99%

Pacman: Tolerating asymmetric data races with unintrusive hardware

Otsuki

Nogueira

et al. 2012

IEEE International Symposium on High-Performance Comp Architecture

View full text Add to dashboard Cite

show abstract

“…However, strong atomicity is more difficult to implement in software transactional memory systems. Most software transactional memory proposals so far have only supported weak atomicity, but recent work, e.g., [13,91,6,2], show how some of these short-comings can be addressed.…”

Section: Strong and Weak Atomicitymentioning

confidence: 99%

“…Further, Shriraman et al [92] suggest four hardware primitives to support high-performance and flexible software transactional memory implementations. Finally, researchers have also proposed to use hardware memory protection mechanisms to implement strongly atomic software transactional memory systems, e.g., [6,2].…”

Section: Hardware Supported Software Transactional Memorymentioning

confidence: 99%

See 1 more Smart Citation

Transactional memory

Grahn¹

2010

Journal of Parallel and Distributed Computing

View full text Add to dashboard Cite

Current and future processor generations are based on multicore architectures where the performance increase comes from an increasing number of cores on a chip. In order to utilize the performance potential of multicore architectures the programs also need to be parallel, but writing parallel programs is a non-trivial task. Transactional memory tries to ease parallel program development by providing atomic and isolated execution of code sequences, enabling software composability and protected access to shared data. In addition, transactional memory has the ability to execute atomic code sequences in parallel as long as no data conflicts occur. Transactional memory implementation proposals exist for both hardware and software, as well as hybrid solutions. This special issue on transactional memory introduces transactional memory as a concept, presents an overview of some of the most important approaches so far, and finally, includes five articles that advances the state-of-the-art in transactional memory research.

show abstract

“…TM has been implemented in hardware (HTM) [2][3][4][5][6][7], software (STM) [8][9][10][11][12][13], or a hybrid of the two (HyTM) [14][15][16][17]. The advantage of HTMs is a low overhead in performing transactional conflict detection, but at the cost of limiting the total accesses of each transaction to the size of the L1 or L2 cache.…”

mentioning

confidence: 99%

Improving Performance by Reducing Aborts in Hardware Transactional Memory

Ansari

Khan

Luján

et al. 2010

High Performance Embedded Architectures and Compilers

View full text Add to dashboard Cite

Abstract. The optimistic nature of Transactional Memory (TM) systems can lead to the concurrent execution of transactions that are later found to conflict. Conflicts degrade scalability, and may lead to aborts that increase wasted work, and degrade performance. A promising approach to reducing conflicts at runtime is dynamically, and transparently, reordering the execution of transactions upon discovery of conflicts. This approach has been explored in Software TMs (STMs), but not in Hardware TMs (HTMs). Furthermore, STM implementations of this approach cannot be ported to HTMs easily. This paper investigates the feasibility of such reordering in HTMs, and presents two designs that are scalable, independent of the on-chip interconnect, require only minor modifications to each core, and add no execution overhead if no conflicts occur. The evaluation takes LogTM-SE as a base line and considers benchmarks with different levels of contention (transactional conflicts). The results show that the preferred design increases HTM performance by up to 17% when contention is low, 57% when contention is high, and never degrades performance. Finally, the designs are orthogonal to LogTM-SE; they require no modification to cache structures, and continue to support transaction virtualization, open and closed unbounded nesting, paging, thread suspension, and thread migration.

show abstract

Using Hardware Memory Protection to Build a High-Performance, Strongly-Atomic Hybrid Transactional Memory

Cited by 35 publications

References 33 publications

Pacman: Tolerating asymmetric data races with unintrusive hardware

Pacman: Tolerating asymmetric data races with unintrusive hardware

Transactional memory

Improving Performance by Reducing Aborts in Hardware Transactional Memory

Contact Info

Product

Resources

About