Dynamically detecting and tolerating IF-Condition Data Races

Abstract

An IF-Condition Invariance Violation (ICIV) occurs when, after a thread has computed the control expression of an IF statement and while it is executing the THEN or ELSE clauses, another thread updates variables in the IF's control expression. An ICIV can be easily detected, and is likely to be a sign of a concurrency bug in the code. Typically, the ICIV is caused by a data race, which we call IF-Condition Data Race (ICR).In this paper, we analyze the data races reported in the bug databases of popular software systems and show that ICRs occur relatively often. Then, we present two techniques to handle ICRs dynamically. They rely on simple code transformations and, in one case, additional hardware help. One of them (SW-IF) detects the races, while the other (HW-IF) detects and prevents them. We evaluate SW-IF and HW-IF using a variety of applications. We show that these new techniques are effective at finding new data race bugs and run with low overhead. Specifically, HW-IF finds 5 new (unreported) race bugs and SW-IF finds 3 of them. In addition, 8-threaded executions of SPLASH-2 codes show that, on average, SW-IF adds 2% execution overhead, while HW-IF adds less than 1%.

Parsnip

“…LARD also demonstrates how to convey sucient information across these layers to restore precision. Other hardware race detectors [21,32,36,38,[41][42][43]60] sacrice soundness and completeness in favor of simpler and faster hardware.…”

TaxDC

“…Knowing programmers' misconceptions can help bug detectors focus on specifications likely to be violated. LC bug researchers have leveraged misconceptions such as "two near-by reads of the same variable should return the same value" [46] and "a condition checked to be true should remain true when used" [53]. Finding #6 reveals that DC-unique common misconceptions, such as "a single hop is faster than double hops", "local computation is faster than one-hop message", "atomic blocks cannot be broken" can help DC bug detection.…”

What change history tells us about thread synchronization

“…For concurrency bug issues, we manually studied the origins of 25 concurrency bugs to see how they are introduced by code revisions. Since this study often requires much deeper understanding of bugs than what change logs provide, some of these 25 bugs are sampled from the change history study mentioned above, and some are from real-world bugs widely used by previous concurrency-bug research [2,15,20,21,29,30,32,42,45,53,60,61,63,66,70,71].…”

“…Although many empirical studies have looked at realworld concurrency bugs [9,14,29,45,70], almost no study has focuses on how developers handle over-synchronization problems in real world. It will be the focus of this section.…”