Optimal prediction of synchronization-preserving races

Abstract

Concurrent programs are notoriously hard to write correctly, as scheduling nondeterminism introduces subtle errors that are both hard to detect and to reproduce. The most common concurrency errors are (data) races, which occur when memory-conflicting actions are executed concurrently. Consequently, considerable effort has been made towards developing efficient techniques for race detection. The most common approach is dynamic race prediction: given an observed, race-free trace σ of a concurrent program, the task is to decide whether events of σ can be correctly reordered to a trace σ * that witnesses a race hidden in σ. In this work we introduce the notion of sync(hronization)-preserving races. A sync-preserving race occurs in σ when there is a witness σ * in which synchronization operations (e.g., acquisition and release of locks) appear in the same order as in σ. This is a broad definition that strictly subsumes the famous notion of happens-before races. Our main results are as follows. First, we develop a sound and complete algorithm for predicting sync-preserving races. For moderate values of parameters like the number of threads, the algorithm runs in Õ( N ) time and space, where N is the length of the trace σ. Second, we show that the problem has a Ω( N /log 2 N ) space lower bound, and thus our algorithm is essentially time and space optimal. Third, we show that predicting races with even just a single reversal of two sync operations is NP-complete and even W1-hard when parameterized by the number of threads. Thus, sync-preservation characterizes exactly the tractability boundary of race prediction, and our algorithm is nearly optimal for the tractable side. Our experiments show that our algorithm is fast in practice, while sync-preservation characterizes races often missed by state-of-the-art methods.

Efficient Data Race Detection of Async-Finish Programs Using Vector Clocks

“…Predictive techniques aim to detect data races that can occur in other correct reorderings of memory accesses by observing one dynamic execution. Predictive techniques use partial order relations that are weaker than HB to allow to reconstruct other valid memory reorderings [37,47,48,66,67,73].…”

Predictive Data Race Detection for GPUs

“…A necessary criterion to ensure correct reorderings of a trace is to maintain write-to-read orders so that the new interleaving explores the same code branches [54,55]. Predictive techniques for CPU programs use partial order relations that are weaker than HB to reconstruct valid memory reorderings and have shown promise in detecting more data races in real-world applications [19,23,24,31,38,42,49,54,55,61].…”

“…Several partial order relations weaker than HB have been proposed for predictive data race detection on CPUs (e.g., causally-precedes (CP) [61], weak-causally-precedes (WCP) [31], schedulable-happens-before (SHB) [41], strong-dependentlyprecedes (SDP) [19], doesn't-commute (DC) [54], M2 [49], weak-doesn't-commute (WDC) [55]), and sync-preserving races (SyncP) [42]. This work uses the WCP relation as the baseline and extends it to the GPU programming model.…”

“…There has been a spurt of work on predictive data race detection for CPU programs [19,23,24,31,41,42,54,55,61]. Predictive techniques observe one dynamic program execution and use partial order relations to reason about valid alternate ordering among accesses to shared variables.…”

A tree clock data structure for causal orderings in concurrent executions

“…In the context of testing multi-threaded programs, partial orders play a crucial role in dynamic race detection techniques, and have been thoroughly exploited to explore tradeoffs between soundness, completeness, and running time of the underlying analysis. Prominent examples include the widespread use of HB [19,24,30,49,60], schedulably-happens-before (SHB) [37], causally-precedes (CP) [63], weak-causally-precedes (WCP) [31], doesn't-commute (DC) [53], and strong/weak-dependently-precedes (SDP/WDP) [28], M2 [48] and SyncP [41]. Beyond race detection, partial orders are often employed to detect and reproduce other concurrency bugs such as atomicity violations [9,26,42], deadlocks [57,65], and other concurrency vulnerabilities [70].…”