RADISH: Always-on sound and complete race detection in software and hardware

Devietti,; Wood, Wood; Strauss,; Ceze,; Qadeer,

doi:10.1109/isca.2012.6237018

Cited by 37 publications

(75 citation statements)

References 38 publications

Supporting

Mentioning

Contrasting

Order By: Relevance

“…Dynamic race detection is integrated in the managed runtime environments RaceTrack [36] and Goldilocks [37]. In [38], [39], it is proposed to integrate hardware acceleration for race detection into CPUs.…”

Section: Related Workmentioning

confidence: 99%

Efficient Data-Race Detection with Dynamic Symbolic Execution

Ibing

2016

Annals of Computer Science and Information Systems

View full text Add to dashboard Cite

Abstract-This paper presents data race detection using dynamic symbolic execution and hybrid lockset / happens-before analysis. Symbolic execution is used to explore the execution tree of multi-threaded software for FIFO scheduling on a single CPU core. Compared to exploring the joint scheduling and execution tree, the combinatorial explosion is drastically reduced. An SMT solver is used to control a debugger's machine interface for adaptive dynamic instrumentation to drive program execution into desired paths. Data races are detected in concrete execution with available static binary instrumentation using hybrid analysis. State interpolation using unsatisfiable cores is employed for path pruning, to avoid exploration of paths that do not contribute to increasing branch coverage. An implementation in Eclipse CDT is described and evaluated with data race test cases from the Juliet C/C++ test suite for program analyzers.

show abstract

Section: Related Workmentioning

confidence: 99%

Efficient Data-Race Detection with Dynamic Symbolic Execution

Ibing

2016

Annals of Computer Science and Information Systems

View full text Add to dashboard Cite

show abstract

“…Earlier exclusively low-level or language-level data-race detectors (e.g., [12,16,44]) have support for marking custom synchronization routines to avoid false races on these accesses and track their synchronization effects. Low-level detection of language-level data races requires similar support, but may also need to distinguish the semantics of such operations based on context.…”

Section: Low-level Detection Of Language-level Racesmentioning

confidence: 99%

Low-level detection of language-level data races with LARD

Wood

Ceze

Grossman

2014

Proceedings of the 19th International Conference on Architectural Support for Programming Languages and Operating Systems

Self Cite

View full text Add to dashboard Cite

Researchers have proposed always-on data-race exceptions as a way to avoid the ill effects of data races, but slow performance of accurate dynamic data-race detection remains a barrier to the adoption of always-on data-race exceptions. Proposals for accurate low-level (e.g., hardware) data-race detection have the potential to reduce this performance barrier. This paper explains why low-level data-race detectors are wrong for programs written in high-level languages (e.g., Java): they miss true data races and report false data races in these programs. To bring the benefits of low-level datarace detection to high-level languages, we design low-level abstractable race detection (LARD), an extension of the interface between low-level data-race detectors and run-time systems that enables accurate language-level data-race detection using low-level detection mechanisms. We implement accurate LARD data-race exception support for Java, coupling a modified Jikes RVM Java virtual machine and a simulated hardware race detector. We evaluate our detector's accuracy against an accurate dynamic Java data-race detector and other low-level race detectors without LARD, showing that naïve accurate low-level data-race detectors suffer from many missed and false language-level races in practice, and that LARD prevents this inaccuracy.

show abstract

“…Many researchers have studied how to detect data races dynamically via software techniques [2,8,9,12,15,16,32,34,35,39,50] and hardware techniques [11,24,30,33,51]. Despite much progress, dynamic data race detection remains expensive on commodity hardware, especially when analyzing unmanaged code.…”

Section: Related Workmentioning

confidence: 99%

“…One approach is to rely on custom hardware [11,24,33,51], but such support is not yet available on commodity processors. Another approach is to tolerate false negatives (i.e., miss detecting some data races), such as by sampling only a portion of the execution [6,22] or data space [13], by refining the granularity of detection at the cost of missing the first race on a variable [50], or by detecting the outcome of races rather than the race itself [43].…”

Section: Introductionmentioning

confidence: 99%

Parallelizing data race detection

Wester

Devecsery

Chen

et al. 2013

Proceedings of the Eighteenth International Conference on Architectural Support for Programming Languages and Operating Systems

View full text Add to dashboard Cite

Detecting data races in multithreaded programs is a crucial part of debugging such programs, but traditional data race detectors are too slow to use routinely. This paper shows how to speed up race detection by spreading the work across multiple cores. Our strategy relies on uniparallelism, which executes time intervals of a program (called epochs) in parallel to provide scalability, but executes all threads from a single epoch on a single core to eliminate locking overhead. We use several techniques to make parallelization effective: dividing race detection into three phases, predicting a subset of the analysis state, eliminating sequential work via transitive reduction, and reducing the work needed to maintain multiple versions of analysis via factorization. We demonstrate our strategy by parallelizing a happens-before detector and a lockset-based detector. We find that uniparallelism can significantly speed up data race detection. With 4× the number of cores as the original application, our strategy speeds up the median execution time by 4.4× for a happens-before detector and 3.3× for a lockset race detector. Even on the same number of cores as the conventional detectors, the ability for uniparallelism to elide analysis locks allows it to reduce the median overhead by 13% for a happens-before detector and 8% for a lockset detector.

show abstract

RADISH: Always-on sound and complete race detection in software and hardware

Cited by 37 publications

References 38 publications

Efficient Data-Race Detection with Dynamic Symbolic Execution

Efficient Data-Race Detection with Dynamic Symbolic Execution

Low-level detection of language-level data races with LARD

Parallelizing data race detection

Contact Info

Product

Resources

About