HARD: Hardware-Assisted Lockset-based Race Detection

Zhou, Pin; Teodorescu, Radu; Zhou, Yuanyuan

doi:10.1109/hpca.2007.346191

Cited by 144 publications

(86 citation statements)

References 41 publications

(75 reference statements)

Supporting

Mentioning

Contrasting

Order By: Relevance

“…Pacman's unique goal makes it very different from hardwarebased race detectors [14,16,19,20,34]. In these schemes, the goal is to characterize and debug races.…”

Section: Discussionmentioning

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

“…Pacman's unique goal makes it very different from hardwarebased race detectors [14,16,19,20,34]. In these schemes, the goal is to characterize and debug races.…”

Section: Discussionmentioning

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

“…Other approaches for detecting general data races in multithreaded programs can be classified into those that use the happens-before algorithm [1,43,44], the lockset algorithm [3,5,45,46], or a hybrid algorithm that combines both approaches [2,4,47]. The key idea behind locksetbased algorithms is to check whether shared variables are protected by at least one lock.…”

Section: Related Workmentioning

confidence: 99%

Isolating bugs in multithreaded programs using execution suppression

et al. 2011

View full text Add to dashboard Cite

SUMMARYMemory-related program failures in multithreaded programs can be caused by a variety of bugs. Concurrency bugs can occur due to unexpected or incorrect thread interleavings during execution. Other kinds of memory bugs, such as buffer overflows and uninitialized reads, may also occur in multithreaded as well as single-threaded programs. Most prior techniques for isolating these bugs are specialized, addressing only one type of concurrency bug or certain types of other memory bugs. The memory corruption caused by these bugs can also undergo significant propagation during program execution. When a program failure finally occurs due to memory corruption, the true root cause of the failure may be effectively concealed as significant portions of memory may have become corrupted. We propose a general framework that can isolate the root cause of any failure in a multithreaded program that involves memory corruption and reveals at least a subset of this memory corruption. This includes three important types of concurrency bugs-data races, atomicity violations, and order violations-as well as other kinds of memory bugs. To account for propagation of memory corruption, our approach uses a dynamic technique called 'execution suppression' that iteratively reveals memory corruption in a failing execution to isolate the true root cause of the failure.

show abstract

“…Even state-of-theart precise software race detection costs roughly 10x overhead [12]. Existing hardware race detectors (e.g., [25,31]) are unsound, lacking the guarantees memory models require. Beyond the requirements of precise and recoverable exceptions, the exact implementation of data-race exception support is not important in this paper.…”

Section: Properties Of Data-race Exceptionsmentioning

confidence: 99%

Data-race exceptions have benefits beyond the memory model

Wood

Ceze

Grossman

2011

Proceedings of the 2011 ACM SIGPLAN Workshop on Memory Systems Performance and Correctness

View full text Add to dashboard Cite

Proposals to treat data races as exceptions provide simplified semantics for shared-memory multithreaded programming languages and memory models by guaranteeing that execution remains data-race-free and sequentially consistent or an exception is raised. However, the high cost of precise race detection has kept the cost-to-benefit ratio of data-race exceptions too high for widespread adoption. Most research to improve this ratio focuses on lowering performance cost.In this position paper, we argue that with small changes in how we view data races, data-race exceptions enable a broad class of benefits beyond the memory model, including performance and simplicity in applications at the runtime system level. When attempted (but exception-raising) racy accesses are treated as legal -but exceptional -behavior, applications can exploit the guarantees of the data-race exception mechanism by performing potentially racy accesses and guiding execution based on whether these potential races manifest as exceptions. We apply these insights to concurrent garbage collection, optimistic synchronization elision, and best-effort automatic recovery from exceptions due to sequential-consistency-violating races.

show abstract

HARD: Hardware-Assisted Lockset-based Race Detection

Cited by 144 publications

References 41 publications

Pacman: Tolerating asymmetric data races with unintrusive hardware

Pacman: Tolerating asymmetric data races with unintrusive hardware

Isolating bugs in multithreaded programs using execution suppression

Data-race exceptions have benefits beyond the memory model

Contact Info

Product

Resources

About