Data Race Prediction for Inaccurate Traces

TL;DR

This paper introduces diagnostic methods to assess the accuracy of data race predictions from traces, accounting for potential inaccuracies in tracing, and empirically compares these methods with existing race predictors.

Contribution

It presents novel diagnostic techniques to evaluate the correctness of race predictions under trace inaccuracies, enhancing the reliability of data race detection.

Findings

Diagnostic methods effectively identify guaranteed races.

Inaccurate traces can lead to false positives in race detection.

Empirical results show improved reliability over existing predictors.

Abstract

Happens-before based data race prediction methods infer from a trace of events a partial order to check if one event happens before another event. If two two write events are unordered, they are in a race. We observe that common tracing methods provide no guarantee that the trace order corresponds to an actual program run. The consequence of inaccurate tracing is that results (races) reported are inaccurate. We introduce diagnostic methods to examine if (1) a race is guaranteed to be correct regardless of any potential inaccuracies, (2) maybe is incorrect due to inaccurate tracing. We have fully implemented the approach and provide for an empirical comparison with state of the art happens-before based race predictors such as FastTrack and SHB.

Tables

Table 1. Table 3 : False positives due to inaccurate release-acquire dependencies.

	moldyn	raytracer	xalan	lusearch	tomcat	avrora	h2
SSHB(FP)	0	0	0	1	2	6	23

Equations

$$\begin{array}[]{ll|l}&1\sharp&2\sharp\\ \hline\cr 1.&\mathit{acq}(y)&\\ 2.&w(x)&\\ 3.&\mathit{rel}(y)\\ 4.&&\mathit{acq}(y)\\ 5.&&w(x)\\ 6.&&\mathit{rel}(y)\end{array}$$

$$\begin{array}[]{ll|l|l}&1\sharp&2\sharp\\ \hline\cr 1.&\mathit{acq}(y)&\\ 2.&w(x)&\\ 3.&&\mathit{acq}(y)\\ 4.&&w(x)\\ 5.&\mathit{rel}(y)\\ 6.&&\mathit{rel}(y)\end{array}$$

$$\begin{array}[]{ll|l}&1\sharp&2\sharp\\ \hline\cr 1.&w(y)&\\ 2.&w(x)&\\ 3.&&r(x)\\ 4.&&w(y)\end{array}$$

$$\begin{array}[]{ll|l}&1\sharp&2\sharp\\ \hline\cr 1.&&r(x)\\ 2.&w(y)&\\ 3.&w(x)&\\ 4.&&w(y)\end{array}$$

$$\begin{array}[]{ll|l|l}&1\sharp&2\sharp&3\sharp\\ \hline\cr 1.&&&w(x)\\ 2.&&r(x)&\\ 3.&&w(y)&\\ 4.&w(y)&&\\ 5.&w(x)&&\end{array}$$

$$\begin{array}[]{ll|l|l}&1\sharp&2\sharp&3\sharp\\ \hline\cr 1.&w(y)&&\\ 2.&w(x)&&\\ 3.&&r(x)&\\ 4.&&w(y)&\\ 5.&&&w(x)\end{array}$$

$$\begin{array}[]{ll|l}&1\sharp&2\sharp\\ \hline\cr 1.&&r(x)\\ 2.&w(y)&\\ 3.&w(x)&\\ 4.&&w(y)\end{array}$$

$$\begin{array}[]{ll|l|l}&1\sharp&2\sharp&3\sharp\\ \hline\cr 1.&w(y)&&\\ 2.&w(x)&&\\ 3.&&r(x)&\\ 4.&&w(y)&\\ 5.&&&w(x)\end{array}$$

$$\begin{array}[]{lcll}T&::=&[]\mid i\sharp e:T&\mbox{Trace}\\ e,f,g&::=&r(x)_{j}\mid w(x)_{j}\mid acq(y)_{j}\mid rel(y)_{j}\par&\mbox{Events}\end{array}$$

$$\begin{array}[]{cc}\mbox{(Acq)}\ \begin{array}[]{lcl}\texttt{acquire(m);}&\Rightarrow&\begin{array}[]{l}\texttt{acquire(m);}\\ \texttt{TRACE\_ACQ(m);}\end{array}\end{array}\\ \mbox{(Rel)}\ \begin{array}[]{lcl}\texttt{release(m);}&\Rightarrow&\begin{array}[]{l}\texttt{TRACE\_REL(m);}\\ \texttt{release(m);}\end{array}\end{array}&\mbox{(RW)}\ \begin{array}[]{lcl}\texttt{x = y;}&\Rightarrow&\begin{array}[]{l}\texttt{tmp = y;}\\ \texttt{TRACE\_READ(y);}\\ \texttt{x = tmp;}\\ \texttt{TRACE\_WRITE(y);}\end{array}\end{array}\end{array}$$

$$\begin{array}[]{lcl}W_{1}&=&\{w(x)_{i}\mid w(x)_{i}\in T\wedge r(x)_{j}\|^{HB}w(x)_{i}\wedge\\ &&\ \ \ \ \ \ \ \ \ \ \neg\exists w(x)_{k}\not=w(x)_{i}.(r(x)_{j}\|^{HB}w(x)_{k}\wedge w(x)_{i}<^{\scriptscriptstyle HB}w(x)_{k})\}\\ W_{2}&=&\{w(x)_{i}\mid w(x)_{i}\in T\wedge w(x)_{i}<^{\scriptscriptstyle HB}r(x)_{j}\wedge\\ &&\ \ \ \ \ \ \ \ \ \ \neg\exists w(x)_{k}\not=w(x)_{i}.(w(x)_{k}<^{\scriptscriptstyle HB}r(x)_{j}\wedge w(x)_{i}<^{\scriptscriptstyle HB}w(x)_{k})\}\end{array}$$

$$\begin{array}[]{ll|l|l}&1\sharp&2\sharp&3\sharp\\ \hline\cr 1.&w(x)&&\\ 2.&&&w(x)\\ 3.&&\mathit{acq}(y)\\ 4.&&w(x)\\ 5.&&\mathit{rel}(y)\\ 6.&\mathit{acq}(y)&\\ 7.&\mathit{rel}(y)&\\ 8.&r(x)&\end{array}$$

$$\begin{array}[]{lccl}\begin{array}[]{ll|l}&1\sharp&2\sharp\\ \hline\cr 1.&&w(x)\\ 2.&w(y)&\\ 3.&r(y)&\\ 4.&w(x)&\\ 5.&&r(x)\\ 6.&&w(y)\end{array}&&&\begin{array}[]{l}W(r(y)_{3})=\{w(y)_{2},w(y)_{6}\}\\ W(r(x)_{5})=\{w(x)_{1},w(x)_{4}\}\\ \\ 1.\ \ w(y)_{2}<^{\scriptscriptstyle\exists SHB}r(y)_{3}\ \ w(x)_{1}<^{\scriptscriptstyle\exists SHB}r(x)_{5}\\ 2.\ \ w(y)_{2}<^{\scriptscriptstyle\exists SHB}r(y)_{3}\ \ w(x)_{4}<^{\scriptscriptstyle\exists SHB}r(x)_{5}\\ 3.\ \ w(y)_{6}<^{\scriptscriptstyle\exists SHB}r(y)_{3}\ \ w(x)_{1}<^{\scriptscriptstyle\exists SHB}r(x)_{5}\end{array}\end{array}$$

$$\begin{array}[]{rcl}V&::=&[i_{1},\dots,i_{n}]\end{array}$$

$$\begin{array}[]{ll|l|l|ll}&1\sharp&2\sharp&3\sharp&cw&cr\\ \hline\cr 1.&w(x)_{[1,0,0]}&\textbf{}&\textbf{}&\{1\sharp 1\}_{x}\\ 2.&&\underline{r(x)}_{[0,1,0]}&\textbf{}&\textbf{}&\{2\sharp 1\}_{x}\\ 3.&&&w(y)_{[0,0,1]}&\{3\sharp 1\}_{y}\\ 4.&&&\underline{w(x)}_{[0,0,2]}&\{1\sharp 1,3\sharp 2\}_{x}\\ 5.&&\underline{w(y)}_{[0,2,0]}&\textbf{}&\{3\sharp 1,2\sharp 2\}_{y}\end{array}$$

$$\begin{array}[]{ll|l|ccc}&1\sharp&2\sharp&Lockset(1)&Lockset(2)&Lockset(x)\\ \hline\cr 1.&\mathit{acq}(y)&&\{y\}\\ 2.&w(x)&&&&\{y\}\\ 3.&&\mathit{acq}(y)&&\{y\}\\ 4.&&w(x)&&&\{y\}\\ 5.&\mathit{rel}(y)&&\emptyset\\ 6.&&\mathit{rel}(y)&&\emptyset\end{array}$$

$$\begin{array}[]{ll|l|l}&1\sharp&2\sharp&3\sharp\\ \hline\cr 1.&\mathit{acq}(y_{1})&&\\ 2.&\mathit{acq}(y_{2})&&\\ 3.&w(x)&&\\ 4.&\mathit{rel}(y_{2})&&\\ 5.&\mathit{rel}(y_{1})&&\\ 6.&&&\mathit{acq}(y_{2})\\ 7.&&&w(x)\\ 8.&&&\mathit{rel}(y_{2})\\ 9.&&\mathit{acq}(y_{1})&\\ 10.&&r(x)&\\ 11.&&\mathit{rel}(y_{1})&\end{array}$$

$$\begin{array}[]{ll|l|l|l|l|l}&1\sharp&2\sharp&3\sharp&4\sharp&5\sharp\\ \hline\cr 1.&&&&&w(x)\\ 2.&&&&w(x)&\\ 3.&&&\mathit{acq}(y_{1})&&\\ 4.&&&w(x)&&\\ 5.&&&\mathit{rel}(y_{1})&&\\ 6.&&\mathit{acq}(y_{2})&&&&\\ 7.&&w(x)&&&&\\ 8.&&\mathit{rel}(y_{2})&&&&\\ 9.&\mathit{acq}(y_{1})&&&&&\\ 10.&\mathit{acq}(y_{2})&&&&&\\ 11.&\mathit{rel}(y_{2})&&&&&\\ 12.&\mathit{rel}(y_{1})&&&&&\\ 13.&r(x)&&&&&\end{array}$$

$$\begin{array}[]{c}e\rightarrow\underbrace{g_{1}\rightarrow\dots\rightarrow g_{n}}_{\dots\rightarrow r^{\prime}\rightarrow\dots w\rightarrow r\rightarrow\dots}\rightarrow f\end{array}$$

$$\begin{array}[]{c}w^{\prime}\rightarrow r^{\prime}\rightarrow\dots w\rightarrow r^{\prime}\rightarrow w^{\prime}\end{array}$$

$$\begin{array}[]{ll|l|l}&1\sharp&2\sharp&3\sharp\\ \hline\cr 1.&y=42&\textbf{}&\textbf{}\\ 2.&x=5&\textbf{}&\textbf{}\\ 3.&&x=5\\ 4.&&&if(x==5)\\ 5.&&&y=43\end{array}$$

$$\begin{array}[]{ll|l|l}&1\sharp&2\sharp&3\sharp\\ \hline\cr 1.&y=42&\textbf{}&\textbf{}\\ 2.&trace_{w}(y,hash(y))&\textbf{}&\textbf{}\\ 3.&x=5&\textbf{}&\textbf{}\\ 4.&trace_{w}(x,hash(x))&\textbf{}&\textbf{}\\ 5.&&&if(x==5)\\ 6.&&x=6\\ 7.&&trace_{w}(x,hash(x))\\ 8.&&&trace_{r}(x,hash(x))\\ 9.&&&y=43\\ 10.&&&trace_{w}(y,hash(y))\end{array}$$

$$\begin{array}[]{ll|l|l}&1\sharp&2\sharp&3\sharp\\ \hline\cr 1.&w(y,42)&\textbf{}&\textbf{}\\ 2.&w(x,5)&\textbf{}&\textbf{}\\ 3.&&w(x,6)\\ 4.&&&r(x,6)\\ 5.&&&w(y,43)\\ \end{array}$$

$$\begin{array}[]{ll|l|l}&1\sharp&2\sharp&3\sharp\\ \hline\cr 1.&x=5&\textbf{}&\textbf{}\\ 2.&trace_{w}(x,hash(x))&\textbf{}&\textbf{}\\ 4.&&y=42&\textbf{}\\ 5.&&trace_{w}(y,hash(y))&\textbf{}\\ 3.&&&if(x==5)\\ 6.&&x=6\\ 7.&&trace_{w}(x,hash(x))\\ 8.&&&trace_{r}(x,hash(x))\\ 9.&&&y=43\\ 10.&&&trace_{w}(y,hash(y))\end{array}$$

Full text

1 Introduction

We consider trace-based dynamic verification methods that attempt to predict a data race based on a single execution run. We assume that relevant program events such as as write/read and acquire/release operations are recorded in a program trace. This trace represents an interleaved execution of the program and is the basis for further analysis.

If two conflicting events, e.g. two writes on the same variable, appear right next to each other in the trace, a data race may arise in the actual program execution. Due to the interleaved recording of events, two conflicting events may not appear right next to each other in the trace. The challenge is to predict if there is a valid trace reordering under which both events take place one after the other.

A popular method to meet such challenges is Lamport’s happens-before model [17]. The idea is to infer from the recorded sequence of events a partial order order relation among events. If two events are ordered then one happens before the other event and therefore there cannot be any conflict among these events. If two, say write, events are unordered then there is a potential conflict. Neither event happens before the other event. Hence, there is an interleaving where both events take place one after the other. This may lead to a conflict. There exists a significant line of research that builds upon the idea of deriving a happens-before relation from the trace of recorded events, e.g. see [20, 8, 25, 10, 16, 21, 19, 14].

These works rely on the assumption that the trace is accurate. By accurate we mean that operations can be executed in the same order as their corresponding events appear in the trace. To derive the sequence of events in a form of a trace, operations need to be instrumented. In case of a write (read) operation, we record an event to represent the fact that a write (read) on some shared variable took place. The same applies to mutex operations such as acquire and release.

The issue is that storing of events is largely unsynchronized to ensure a low run-time overhead. Hence, the sequence of events recorded in a trace may be inaccurate and may not reflect an actual program run. For happens-before based analyses this means that release-acquire and write-read happens-before dependencies derived from the trace are inaccurate. Then, a predicted race may not be feasible (false positive) and an obvious race may be missed (false negative). These are scenarios that potentially appear in practice.

Concretely, we consider the happens-before based data race predictors FastTrack [8] and SHB [19]. FastTrack is only sound for the first race reported. FastTrack ignores write-read dependencies and therefore subsequent races reported may be false positives. SHB on the other hand includes write-read dependencies and comes with the guarantee that no false positives arise. This guarantee only holds under the assumption that the trace is accurate. However, common tracing tools such as RoadRunner [9] may produce inaccurate traces.

Our idea is to provide diagnostic methods to examine the data races reported by happens-before based race predictors. We provide methods to check if a race is (1) guaranteed to be correct regardless of any potential inaccuracies during tracing, (2) maybe incorrect due to inaccurate tracing. Applied to FastTrack and SHB, we can provide the following diagnostic information. If a FastTrack/SHB race is a guaranteed race we can be certain that (inaccurate) write-read dependencies have no impact on the analysis result. If a SHB race is a maybe race, then tracing could be inaccurate. If a FastTrack race is a maybe race, then this could be a false positive

In summary, our contributions are:

• •

We introduce an instrumentation scheme that guarantees accurate tracing of release-acquire dependencies (Section 3).

• •

We develop a family of happens-before relations that take into account inaccurately traced write-read dependencies (Section 4).

• •

We propose diagnostic methods to examine if data races reported are affected by inaccurately traced write-read dependencies (Section 5).

• •

We have fully implemented these diagnostic methods and provide for an empirical comparison with the results provided by FastTrack and SHB (Section 6).

The upcoming section explains by example the issue of inaccurate tracing and its impact on happens-before based data race prediction methods. We also motivate our method how to check if the predicted race is affected by inaccurate tracing. Section 3 reviews instrumentation and tracing. Section 7 covers related work. Section 8 concludes.

Our implementation is available via

https://github.com/KaiSta/gopherlyzer-GuaranteedRaces.

The paper contains an appendix with further details such as proofs of the results stated in this paper.

2 Overview

We identify two scenarios where inaccurate tracing affects the precision of the happens-before relation derived from the trace.

2.1 Inaccurate Tracing of Release-Acquire Dependencies

We consider the program in Figure 1 (on the left). We assume a mutex referenced by variable $y$ and some shared variable $x$. In the main thread, referred to as thread 2, we acquire the mutex, write to $x$, and then release the mutex. The main thread creates another thread, referred to as thread 1, which effectively performs the same sequence of operations. We assume that the program is instrumented such that the execution of the program yields a trace. A trace is a sequence of events that took place and is meant to represent the interleaved execution of the various threads found in the program. The events we are interested in here are acquire, release, read and write.

Subfigure 1(b) shows such a trace. We use a tabular notation to record for each event, the kind of event, its position in the trace and the thread id of the thread in which the event took place. For example, an acquire event on $y$ in thread 1 is recorded at trace position 1. We use notation $1\sharp acq(y)_{1}$ to represent this information. We write $2\sharp w(x)_{5}$ to denote the write event on $x$ in thread 2 recorded at trace position 5. We often skip the thread identifier and write $w(x)_{5}$ for short.

A well-explored data race prediction approach is to infer from the trace a happens-before relation. If two conflicting events, e.g. two writes on the same variable, are not in a happens-before (HB) relation we argue that the trace can be reordered such that both events appear next to each other in the trace. This shows that there is a potential data race.

For the trace in Subfigure 1(b) we infer that (a) $w(x)_{2}<rel(y)_{3}$, (b) $rel(y)_{3}<acq(y)_{4}$, and (c) $acq(y)_{4}<w(x)_{5}$. HB relations (a) and (c) are due to the program order. That is, for each thread events take place in the order as they appear in the program text. HB relation (b) is due to a release-acquire dependency. An acquire can only be performed once the mutex is released. Hence, we impose (b). Based on the above HB order, we find that $w(x)_{2}<w(x)_{5}$. We conclude that the two writes are not in a race.

The issue we investigate in this work is that tracing may be inaccurate. The program text is instrumented to record an event for each operation we are interested in. To ensure a low run-time overhead, there is almost no synchronization among concurrently taking place recordings. This may lead to some inaccurate trace.

The example in Figure 1 has two threads of execution. The release operation in thread 1 takes place before the acquire and write operation in thread 2. Assuming that all events are recorded after the respective operation took place, it is entirely possible that the recording of the release event will be overtaken by the acquire and write event. This then results in the (inaccurate) trace reported in Subfigure 1(c).

Like above, we find the program order relations (a) and (c). However, the release-acquire dependency is lost. In the recorded trace in Subfigure 1(c), the release in thread 1 does not precede the acquire in thread 2. The consequence is that the two writes appear unordered and the analysis (falsely) signals that there is a potential race.

The above scenario may arise in practice. The RoadRunner tracing tool [9] possibly yields the inaccurate trace in Subfigure 1(c). A happens-before based data race predictor such as FastTrack [8] will then (wrongly) signal a write-write race. This is clearly a false positive as for any execution run the writes are mutually exclusive.

2.2 Inaccurate Tracing of Write-Read Dependencies

Another source of inaccurate tracing are unsynchronized reads and writes. Write-read dependencies derived from the trace may not be accurate and we may then encounter false positives and negatives.

Consider the program in Figure 2 (on the left). We find two threads where the main thread is referred to as thread 2. We assume shared variables $x$ and $y$. We include their declaration and initial values (zero). This did not matter for our earlier example. We run the program where we assume that thread 1 executes first. The resulting trace is shown in Subfigure 2(b). For brevity, the trace does not contain the initial writes to x and y.

For the trace in Subfigure 2(b) we infer that (a) $w(y)_{1}<w(x)_{2}$, (b) $r(x)_{3}<w(y)_{4}$, and (c) $w(x)_{2}<r(x)_{3}$. HB relations (a) and (b) are due to the program order. HB relation (c) is due to a write-read dependency. As the control flow may be affected by the read value, we assume that the read event happens after the preceding write. Hence, we impose (c). Based on the above HB order we then find that $w(y)_{1}<w(y)_{4}$. We conclude that the two writes on y are not in a race.

We take a closer look at the recording of events when running the program. After each read/write operation, we record a read/write event. We consider a specific execution run where thread 1 executes first followed by the if-statement in the main thread. In detail, after execution of y = 1 and x = 1 in thread 1, we execute the if-condition x == 1 followed by y = 2 in the main thread (2). For the resulting events we observe the following.

Thread 1 records the events $w(y)$ and $w(x)$ and the main thread records the events $r(x)$ and $w(y)$. For each thread, events are recorded in the sequence as they arise. For example, for thread 1, we find that $w(y)$ appears before $w(x)$ in the trace. Recording of concurrent events is not synchronized. Hence, it is possible that the recording of $r(x)$ takes place before the recording of $w(x)$. Then, we encounter the trace in Subfigure 2(c).

This trace implies the same program order relations (a) and (b) as discovered for the trace in Subfigure 2(b). However, the write-read dependency (c) is lost because $w(x)_{2}$ no longer precedes $r(x)_{3}$. Then, the two write events on $y$ are unordered and the analysis (falsely) signals that there is a potential race.

The above scenario may arise in practice. A happens-before based data race predictor such as SHB [19] that imposes write-read dependencies then reports a race where where there is actually none. The initial value of $x$ is zero. The then-statement will only be reached once thread 1 is fully executed. Hence, the two writes on $y$ always happen one after the other. Hence, there is no write-write race on $y$.

Figure 3 shows another example. For this case, inaccurate tracing of write-read dependencies omits a race. For the trace in Subfigure 3(c) we infer that (a) $w(y)_{1}<w(x)_{2}$, (b) $w(x)_{2}<r(x)_{3}$, (c) $r(x)_{3}<w(y)_{4}$. HB relations (a) and (c) are due to the program order. Relation (b) is due to a write-read dependency. We conclude that $w(y)_{1}$ happens-before $w(y)_{4}$. Hence, there is no race. This reasoning is wrong due to inaccurately traced events. Based on the actual (accurate) trace in Subfigure 3(b), we find that the two writes on $y$ are in a race.

2.3 Our Approach

Inaccurate tracing of release-acquire and write-read dependencies affects the precision of happens-before based data race predictors. See the above examples. In case of release-acquire, we will propose an alternative (yet simple) instrumentation scheme that by construction guarantees that all release/acquire dependencies are accurately traced. No such guarantees can be given for write-read dependencies unless some heavy-weight instrumentation scheme is used that severely impacts the run-time performance. Hence, we have to face the possibility that write-read dependencies derived from the trace are not accurate.

Our approach to deal with inaccurate write-read dependencies is as follows. The standard write-read dependency relation imposes a happens-before relation from the nearest write in the trace to the read. We take into account inaccurate tracing by considering all potential write dependency candidates. A write is a potential write-read dependency candidate for a read if (1) the read and write are unsynchronized, or (2) the write immediately happens before the read with no other write in between.

We then build a graph to examine pairs of events that are in a race. For each standard happens-before relation we add an edge. In addition, we add an edge from a write to a read if the write is a potential write-read dependency candidate for that read. Thus, we take into account inaccuracies that we might experience during tracing of unsynchronized reads/writes. For each data race pair we then test if there is a path that connects both events. If there is a path, then we classify the pair as a maybe data race. If there is no path, then we classify the pair is a guaranteed data race.

We revisit our earlier examples. Figure 4 shows the resulting edges (on the right) for the (inaccurate) trace in Subfigure 2(c). Solid edges correspond to standard happens-before relations. Dotted edges correspond to potential write-read dependencies. There is only one write candidate for the read here. The standard happens-before analysis reports for the pair $(w(y)_{2},w(y)_{4})$ that the events are unordered. There is a path from $w(y)_{2}$ to $w(y)_{4}$. Hence, this is a maybe data race because there is a possible choice of write-read dependency under which both writes are not in a race.

Figure 5 shows the (inaccurate) trace from Subfigure 3(c). Edges are on the right. There are two write candidates for the read that could possibly form a write-read dependency. We are conservative and include all possibilities. Events $w(x)_{2}$ and $w(x)_{5}$ are unordered under the standard happens-before relation (considering solid edges only). Considering the entire graph, solid and dotted edges, we find that there is no path that connects both events. Hence, the pair $(w(x)_{2},w(x)_{5})$ is a guaranteed data race. Events $w(y)_{1}$ and $w(y)_{4}$ are also unordered but there is a path that connects both events. Hence, this pair represents a maybe data race.

Our diagnostic method to identify maybe and guaranteed data races requires two phases. The first phase resembles existing algorithms such as FastTrack and SHB. We achieve the same (worst-case) time complexity but require (worst-case) quadratic, in the size of the trace, space to store edges. We therefore apply our method always offline, unlike FastTrack and SHB that can applied online while the program is running. The second phase then examines data races reported in the first phase. For each such data race pair, we perform a graph search that requires (worst-case) quadratic, in the size of the trace, time.

We have fully implemented our approach. Benchmarks for some real-world examples show that our method is practical and is useful to examine the results reported by FastTrack [8] and SHB [19]. FastTrack ignores write-read dependencies whereas SHB imposes write-read dependencies. Hence, FastTrack is only sound for the first race reported.

If a FastTrack/SHB race is a guaranteed race we can be certain that (inaccurate) write-read dependencies have no impact on the analysis result. If a SHB race is a maybe race, then tracing could be inaccurate. If a FastTrack race is a maybe race, then this could be a false positive because FastTrack ignores write-read dependencies. The details of our approach follow below.

3 Instrumentation and Tracing

We assume concurrent programs making use of shared variables and acquire/release (a.k.a. lock/unlock) primitives. Further constructs such as fork and join are omitted for brevity. Programs will be instrumented to derive a trace of events when running the program. The information recorded in the trace is of the following form.

Definition 1 (Run-Time Traces and Events)

[TABLE]

A trace $T$ is a list of events. We adopt Haskell notation for lists and assume that the list of objects $[o_{1},\dots,o_{n}]$ is a shorthand for $o_{1}:\dots:o_{n}:[]$. We write   ++ to denote the concatenation operator among lists. For each event $e$, we record the thread id number $i$ in which the event took place, written $i\sharp e$. We write $r(x)_{j}$ and $w(x)_{j}$ to denote a read and write event on shared variable $x$ at position $j$. We write $acq(y)_{j}$ and $rel(y)_{j}$ to denote a lock and unlock event on mutex $y$ The number $j$ represents the position of the event in the trace. We sometimes omit the thread id and position for brevity.

To instrument programs we assume a syntactic pre-processing step where the source program is manipulated as follows.

Definition 2 (Instrumentation)

[TABLE]

We assume some (trace recording) primitives TRACE_X that store the respective events in some trace. For example, TRACE_ACQ(m) issues the event $i\sharp acq(m)_{k}$ and stores this event at trace position $k$. For brevity, we keep symbolic names such as $m$. In the actual instrumentation, they will be represented via hash codes. A further technical detail is that the trace recording primitives must have access to the thread id $i$ associated to this program text. We also need to increment the current trace position $k$.

To avoid conflicts when generating and storing events, each TRACE_X operation is executed atomically. We assume a program execution model where an atomically executed operation issues a memory barrier. A consequence of introducing these memory barriers is that the above instrumentation scheme enforces a sequential consistency memory model [1]. That is, for each thread all reads and writes are executed in the sequence as they appear in the program text.

We consider the instrumentation of acquire/release operations. We assume that for each acquire there is a matching release operation in the same thread. This is a common requirement that must be fulfilled by mutex operations. Each acquire issues the event after the operation has executed. In case of release, we issue the event before the release operation executes. This is done for the following reason.

After the acquire operation is executed no other acquire event for the same mutex will be issued (due to mutual exclusion). We first record the release event before we actually perform the release operation. Hence, the release event is issued right after the acquire event and there can no be other competing release events on the same mutex. The matching release must be in the same thread. Hence, the acquire and release event are issued in sequence and this sequence is preserved when storing events.

In case of a prematurely terminated program where some acquire lacks a matching release, we introduce a dummy release event. We conclude that the instrumentation and tracing scheme laid out above, enjoys the following guarantees:

INST_PO:

Events in a thread are traced in the order as they appear in the program text.

INST_RA:

Release and acquire events are traced in the order as they are executed and therefore each acquire can be properly matched with its corresponding release by scanning through the trace.

We consider in more detail the instrumentation of reads and writes. For reads and writes we issue a trace recording primitive after the actual operation took place. To ensure a low run-time overhead and avoid blocking of the running thread, trace recording relies on lock-free operations and/or perform the trace recording in a separate helper thread. The issue is that intra-thread event recordings may be out of sync relative to the actual program execution order. Hence, it is possible that the event of an earlier read appears after some write event if both event recordings take place concurrently. Recording the read/write event before the actual operation does not help either.

We would need to synchronize the actual operation and the recording of the associated event by carrying out both steps atomically. Under a pessimistic scheme, shared operations on non-conflicting variables would need to be synchronized as well. This is clearly not practical. The work reported in [6] explores some more optimistic schemes. A managed run-time is assumed to track dependencies. The run-time overhead can still be significant as the experimental results show.

Hence, we assume a much more light-weight instrumentation scheme where there is no synchronization among concurrently taking place tracing operations. Such a scheme for example is applied by the popular RoadRunner tracing tool [9]. The down-side is that there is no guarantee that read/write events that are not protected by a mutex are accurately ordered in the trace. To deal with such inaccurate traces we apply some diagnostic methods to distinguish between guaranteed and maybe data races.

4 Happens-Before Relation

We revisit the standard happens-before (HB) relation and the schedulable happens-before (SHB) relation that incorporates write-read dependencies. SHB determines write-read dependencies based on the position in the trace. We assume that tracing of unsynchronized reads and writes is inaccurate and therefore some write-read dependencies are missing or wrongly imposed. We introduce more general SHB relations that take into account such inaccuracies. This provides the theoretical basis for our diagnostic methods in the upcoming section.

First, we introduce some notation and helper functions. For trace $T$, we assume some functions to access the thread id and position of $e$. We define $\mathit{thread}_{{\scriptstyle T}}(e)=j$ if $T=T_{1}\ \texttt{++}\ [j\sharp e]\ \texttt{++}\ T_{2}$ for some traces $T_{1},T_{2}$. We define $\mathit{pos}_{{\scriptstyle T}}(r(x)_{j})=j$, $\mathit{pos}_{{\scriptstyle T}}(w(x)_{j})=j$, $\mathit{pos}_{{\scriptstyle T}}(acq(y)_{j})=j$ and $\mathit{pos}_{{\scriptstyle T}}(rel(y)_{j})=j$ to extract the trace position from an event. We assume that the trace position is correct: If $\mathit{pos}_{{\scriptstyle T}}(e)=n$ then $T=i_{1}\sharp e_{1}:\dots:i_{n-1}\sharp e_{n-1}:i\sharp e:T^{\prime}$ for some events $i_{k}\sharp e_{k}$ and trace $T^{\prime}$. We sometimes drop the component $T$ and write $\mathit{thread}(e)$ and $\mathit{pos}(e)$ for short.

For trace $T$, we define $\mathit{events}(T)=\{e\mid\exists T_{1},T_{2},j.T=T_{1}\ \texttt{++}[j\sharp e]\ \texttt{++}T_{2}\}$ to be the set of events in $T$. We write $e\in T$ if $e\in\mathit{events}(T)$.

We consider the standard happens-before (ordering) relation among events.

Definition 3 (Happens-Before)

Let $T$ be a trace. We define a relation $<^{\scriptscriptstyle HB}$ among trace events as the smallest partial order such that the following holds:

Program order (PO):

Let $e,f\in T$. Then, $e<^{\scriptscriptstyle HB}f$ iff $\mathit{thread}(e)=\mathit{thread}(f)$ and $\mathit{pos}(e)<\mathit{pos}(f)$.

Release-acquire dependency (RAD):

Let $rel(y)_{j},acq(y)_{k}\in T$. Then, we define $rel(y)_{j}<^{\scriptscriptstyle HB}acq(y)_{k}$ iff $j<k$ where $\mathit{thread}(rel(y)_{j})\not=\mathit{thread}(acq(y)_{k})$ and for all $e\in T$ where $j<\mathit{pos}(e)$, $\mathit{pos}(e)<k$ and $\mathit{thread}(rel(y)_{j})\not=\mathit{thread}(e)$ we find that $e$ is not an acquire event on $y$.

We refer to $T<^{\scriptscriptstyle HB}{}$ as the happens-before relation derived from trace $T$.

We say two events $e,f\in T$ are unsynchronized with respect to each other if neither $e<^{\scriptscriptstyle HB}f$, nor $f<^{\scriptscriptstyle HB}e$ holds. In such a situation, we write $e\|^{HB}f$.

The guarantees INST_PO and INST_RA of our instrumentation and tracing scheme ensure that the happens-before relation derived from a trace is not affected by any inaccuracies during tracing. Hence, for two events $e,f$ in happens-before relation $e<^{\scriptscriptstyle HB}f$ we guarantee that $e$ was executed before $f$.

Mathur and coworkers [19] extend the happens-before relation by imposing the following condition.

Definition 4 (Schedulable Happens-Before [19])

Let $T$ be a trace. We define a relation $<^{\scriptscriptstyle SHB}$ among trace events as the smallest partial order that satisfies PO and RAD from Definition 3 and the following additional condition:

Write-read dependency (WRD):

Let $r(x)_{j},w(x)_{k}\in T$. Then, $w(x)_{j}<^{\scriptscriptstyle SHB}r(x)_{k}$ iff $j<k$ and for all $e\in T$ where $j<\mathit{pos}(e)$ and $\mathit{pos}(e)<k$ we find that $e$ is not a write event on $x$.

We refer to $<^{\scriptscriptstyle SHB}$ as the schedulable happens-before relation derived from trace $T$.

Condition WRD states that if a write precedes a read and there is no other write in between, then the read must happen after that write. The intention is that write-read dependencies affecting the program execution must be respected when analyzing the trace. Without the WRD condition, we may wrongly conclude that two events are unsynchronized. This potentially leads to false positives in case of happens-before based data race prediction.

Recall the program in Figure 1(a) and the trace in Figure 1(b) obtained from running the instrumented program. The read value at trace position $2$ depends on the prior write at trace position $1$. The control flow is affected by the read value. The if-condition holds and therefore y = 2 is executed. This results in the write event at trace position $3$. Based on the schedulable happens-before relation, we conclude that the write at trace position $1$ happens before the write at trace position $3$. In detail, we find $w(x)_{1}<^{\scriptscriptstyle SHB}r(x)_{2}$ due to the WRD condition and $r(x)_{2}<^{\scriptscriptstyle SHB}w(x)_{3}$ due to the PO condition. Hence, $w(x)_{1}<^{\scriptscriptstyle SHB}w(x)_{3}$.

Without the WRD condition, $w(x)_{1}$ and $w(x)_{3}$ appear to be unsynchronized. Hence, we predict that there must be an interleaved execution where both events appear right next to each other in the resulting trace. This prediction is clearly wrong as $w(x)_{1}$ must happen before $w(x)_{3}$ by observing the possible control flow when executing the program.

We conclude that the WRD condition is important to make valid predictions about the run-time behavior of programs. The WRD condition in Definition 4 identifies the write that affects the read based on the position in the trace. In the presence of inaccurate tracing, the event of the actual last write that affects the read might not be the closest write event in terms of the position in the trace. Recall the examples in Section 2. Hence, the schedulable happens-before relation derived from the trace may suggest trace reorderings that do not correspond to any actual (interleaved) program execution. Hence, the WRD condition is sensitive to the accuracy of tracing.

To make valid predictions in the presence of inaccurate tracing, we generalize the WRD condition as follows. Instead of characterizing the last write that precedes the read in terms of the position in the trace, we characterize all potential WRD candidates. Potential WRD candidates are either (1) writes that are unsynchronized with respect to the read, or (2) writes that immediately happen before that read. To identify cases (1) and (2) we rely on the standard happens-before relation $<^{\scriptscriptstyle HB}$. Recall that $<^{\scriptscriptstyle HB}$ is not affected by inaccurate tracing of unsynchronized reads and writes.

Definition 5 (Read/Write Events)

Let $T$ be a well-formed trace. We define $T^{rw}_{x}$ as the set of all read/write events in $T$ on some variable $x$.

Definition 6 (WRD Candidates)

Let $T$ be a trace and $r(x)_{j}\in T$. We define

[TABLE]

Let $W=W_{1}\cup W_{2}$. Then, we refer to $W$ as the WRD candidates w.r.t. $r(x)_{j}$.

The set $W_{1}$ covers all writes that are unsynchronized with respect to the read. We refer to $W_{1}$ as the unsynchronized WRD candidates. The set $W_{2}$ covers all writes that happen before that read. We refer to $W_{2}$ as the synchronized WRD candidates. For both cases, the write must be closest to the read. In case of $W_{1}$, this is achieved by side condition $\neg\exists w(x)_{k}\not=w(x)_{i}.(r(x)_{j}\|^{HB}w(x)_{k}\wedge w(x)_{i}<^{\scriptscriptstyle HB}w(x)_{k})$ and in case of $W_{2}$ by the side condition $\neg\exists w(x)_{k}\not=w(x)_{i}.(w(x)_{k}<^{\scriptscriptstyle HB}r(x)_{j}\wedge w(x)_{i}<^{\scriptscriptstyle HB}w(x)_{k})$. Depending on the context, we write $W(e),W_{1}(e),W_{2}(e)$ to highlight that we consider the WRD candidates for a specific read event $e$.

Example 1

Consider the following trace.

[TABLE]

Consider the read event $r(x)_{8}$. The WRD candidates as characterized by Definition 6 are as follows: $W_{1}=\{w(x)_{2}\}$ and $W_{2}=\{w(x)_{1},w(x)_{4}\}$.

Event $w(x)_{2}\in W_{1}$ because $r(x)_{8}<^{\scriptscriptstyle HB}w(x)_{2}$ and there is no other write that happens in between. Event $w(x)_{2}$ is the closest write based on the trace position. Hence, this is the (sole) WRD candidate as characterized by Definition 4.

In addition, we consider $w(x)_{1}$ and $w(x)_{4}\in W_{2}$. Both writes are unsynchronized with respect to $r(x)_{8}$ as well as $w(x)_{2}$.

Proposition 1

The write event as characterized by Definition 4 must be in one of the sets $W_{1}$ and $W_{2}$.

Proposition 2

Let $T$ be a trace and $e$ be some read event. The number of elements in $W_{1}(e)$ is $O(k)$ where $k$ is the number of threads. The same applies to $W_{2}(e)$.

The set $W_{1}\cup W_{2}$ is a conservative approximation of all potential writes that may affect the read. Instead of imposing the WRD condition for a single write candidate as done for SHB, we consider the following variants. We (a) impose all WRD candidates, (b) pick one of the WRD candidates as characterized by Definition 6. First, we consider variant (a).

Definition 7 (Strong Schedulable Happens-Before)

Let $T$ be a trace. We define a relation $<^{\scriptscriptstyle\forall SHB}$ among trace events as the smallest partial order that satisfies PO and RAD from Definition 3 and the following additional condition:

Strong write-read dependency (StrongWRD):

Let $r(x)_{j}\in T$ and $W(r(x)_{j})$ its set of WRD candidates. Then, $e<^{\scriptscriptstyle\forall SHB}r(x)_{j}$ for each $e\in W(r(x)_{j})$.

We refer to $<^{\scriptscriptstyle\forall SHB}$ as the strong schedulable happens-before relation derived from trace $T$.

A strong schedulable happens-before relation may not exist.

Example 2

Consider the trace $T=[1\sharp r(y)_{1},1\sharp w(x)_{2},2\sharp r(x)_{3},2\sharp w(y)_{4}]$. Based on the program order, we find $r(y)_{1}<^{\scriptscriptstyle HB}w(x)_{2}$ and $r(x)_{3}<^{\scriptscriptstyle HB}w(y)_{4}$. Furthermore, $W(r(y)_{1})=\{w(y)_{4}\}$ and $W(r(x)_{3})=\{w(x)_{2}\}$. The strong schedule happens-before relation additionally imposes $w(y)_{4}<^{\scriptscriptstyle\forall SHB}r(y)_{1}$ and $w(x)_{2}<^{\scriptscriptstyle\forall SHB}r(x)_{3}$. In combination with the HB relations we encounter a cycle. Consider $r(y)_{1}<^{\scriptscriptstyle HB}\ w(x)_{2}<^{\scriptscriptstyle\forall SHB}\ r(x)_{3}<^{\scriptscriptstyle HB}\ w(y)_{4}<^{\scriptscriptstyle\forall SHB}\ r(y)_{1}$. This contradicts the properties of a partial order. Hence, the strong schedulable happens-before relation does not exist for this case.

Next, we consider variant (b). Instead of imposing all WRD candidates, we (arbitrarily) pick one of the candidates.

Definition 8 (Some Schedulable Happens-Before)

Let $T$ be a trace. We define a relation $<^{\scriptscriptstyle\exists SHB}$ among trace events as the smallest partial order that satisfies PO and RAD from Definition 3 and the following additional condition:

Some write-read dependency (SomeWRD):

Let $r(x)_{j}\in T$ and $W(r(x)_{j})$ its set of WRD candidates. Then, $e<^{\scriptscriptstyle\exists SHB}r(x)_{j}$ for some $e\in W(r(x)_{j})$.

We refer to $<^{\scriptscriptstyle\exists SHB}$ as the some schedulable happens-before relation derived from trace $T$.

We expect that an instance of $<^{\scriptscriptstyle\exists SHB}$ always exists. This is only the case if there is an initial write for each read. Recall Example 2. For each read, there is only one choice of WRD candidate. As the example shows, the resulting order relation has a cycle.

To ensure that an instance of $<^{\scriptscriptstyle\exists SHB}$ exists, we demand that for each read there must be always a write happening before that read. Then, $<^{\scriptscriptstyle SHB}$ is a specific instance of a $<^{\scriptscriptstyle\exists SHB}$.

Definition 9 (Initial Write)

Let $T$ be a trace and $<^{\scriptscriptstyle HB}$ the happens-before relation derived from $T$. We say that each read event $e$ in $T$ enjoys an initial write if $W_{2}(e)\not=\{\}$.

Proposition 3

Let $T$ be a trace where each read event enjoys an initial write. Then, $<^{\scriptscriptstyle SHB}$ is an instance of $<^{\scriptscriptstyle\exists SHB}$.

Besides $<^{\scriptscriptstyle SHB}$, we also show that $<^{\scriptscriptstyle HB}$ is an instance.

Proposition 4

Let $T$ be a trace where each read event enjoys an initial write. Then, $<^{\scriptscriptstyle HB}$ is an instance of $<^{\scriptscriptstyle\exists SHB}$.

In general, the resulting $<^{\scriptscriptstyle\exists SHB}$ relations are distinct from $<^{\scriptscriptstyle HB}$ and $<^{\scriptscriptstyle SHB}$.

Example 3

Consider the following trace (on the left) and the resulting WRD candidates and $<^{\scriptscriptstyle\exists SHB}$ instances (on the right).

[TABLE]

The first instance corresponds to $<^{\scriptscriptstyle HB}$ and the second instance to $<^{\scriptscriptstyle SHB}$. The third instance is different from HB and SHB.

The example shows that not all combinations (four in our case) are feasible. For $w(y)_{6}<^{\scriptscriptstyle\exists SHB}r(y)_{3}$ the only choice left is $w(x)_{1}<^{\scriptscriptstyle\exists SHB}r(x)_{5}$ because $w(x)_{4}<^{\scriptscriptstyle\exists SHB}r(x)_{5}$ leads to a cycle.

5 Data Race Diagnosis

We make use of the results of the previous section to provide diagnostic information to examine if data races reported are affected by inaccurately traced write-read dependencies. For brevity, we only consider write-write races. Write-read cases will be covered when discussing our implementation in the upcoming section.

Definition 10 (Write-Write Data Races)

Let $T$ be a trace where $e,f\in T$ are two write events on the same variable. We say $(e,f)$ are in a write-write HB data race if neither $e<^{\scriptscriptstyle HB}f$ nor $f<^{\scriptscriptstyle HB}e$.

We say $(e,f)$ are in a write-write $\forall$SHB data race if neither $e<^{\scriptscriptstyle\forall SHB}f$ nor $f<^{\scriptscriptstyle\forall SHB}e$.

Let $<^{\scriptscriptstyle\exists SHB}$ be a specific choice of a some schedulable happens-before relation. We say $(e,f)$ are in a write-write $\exists$SHB data race if neither $e<^{\scriptscriptstyle\exists SHB}f$ nor $f<^{\scriptscriptstyle\exists SHB}e$.

We wish to answer the following questions.

Q1: Given a HB data race, is this a race for any instance of $<^{\scriptscriptstyle\exists SHB}$? 2. 2.

Q2: Given a HB data race, does an instance of $<^{\scriptscriptstyle\exists SHB}$ exists under which the race goes away?

A yes to the first question means inaccurate tracing had no impact. A yes to the second question means that we cannot be sure. To check both questions we construct a graph from the trace.

Definition 11

Let $T$ be a trace. We assume that for each read event $e\in T$ we have available the set $W(e)$ of WRD candidates. We define a graph $G=(N,E)$ with a set $N$ of nodes and set $E$ of directed edges as follows:

• •

$N=\{e\mid e\in T\}$.

• •

E=\{e\stackrel{{\scriptstyle HB}}{{\rightarrow}}f\mid e,f\in T\wedge e<^{\scriptscriptstyle HB}f\}\cup\{e\stackrel{{\scriptstyle W(r)}}{{\rightarrow}}f\mid\mbox{r read event}\wedge e\in W(r)\}.

We refer to $G$ as the graph derived from $T$.

Let $e,f\in N$. We say that there is a path from $e$ to $f$, if we find $g_{1},\dots,g_{n}\in N$ such that $e\rightarrow g_{1}\rightarrow\dots\rightarrow g_{n}\rightarrow f$ where all nodes are distinct.

Edges are derived from either a HB relation or some WRD candidate. They are labeled to keep track of their origin. If this information does not matter, we write $e\rightarrow f$ for short.

The graph includes all possible combinations of WRD candidates. If there is no path between two events involved in a data race, we can answer Q1 positively.

Proposition 5 (Guaranteed Data Race)

Let $T$ be a trace and $G$ be the graph derived from $G$. Let $(e,f)$ be a pair of events that are in a write-write HB data race. If there is no path between $e$ and $f$ then for any choice of $<^{\scriptscriptstyle\exists SHB}$ we have that $(e,f)$ are in a write-write $\exists$SHB data race.

The above statements only applies to those $<^{\scriptscriptstyle\exists SHB}$ relations that actually constitute a partial order. Recall that no every choice of WRD candidates results in a partial order and $<^{\scriptscriptstyle\forall SHB}$ does not necessarily exist. See Examples 2 and 3.

To answer Q2 we need to find path for a particular choice of WRD candidates.

Proposition 6 (Maybe Data Race)

Let $T$ be a trace and $G$ be the graph derived from $G$. Let $(e,f)$ be a pair of events that are in a write-write HB data race. We assume that there exists a path among $e$ and $f$ with distinct nodes and the label $W(r)$ appears at most once. Then, there exists $<^{\scriptscriptstyle\exists SHB}$ under which $e$ and $f$ are not in a race.

6 Implementation and Experiments

6.1 Implementation

To implement the diagnostic methods described in the previous section, we make use of an extended version of the FastTrack algorithm from [8] to (1) identify HB data race pairs and to (2) build up the graph of HB and WRD candidate edges (see Definition 11). See Algorithm 1.

We maintain several vector clocks.

Definition 12 (Vector Clocks)

A vector clock $V$ is a list of time stamps of the following form.

[TABLE]

We assume vector clocks are of a fixed size $n$. Time stamps are natural numbers and each time stamp position $j$ corresponds to the thread with identifier $j$.

We write $V[j]$ to access the time stamp at position $j$. We write ${\sf inc}(V,j)$ as a short-hand for incrementing the vector clock $V$ at position $j$ by one.

For each thread $i$ we maintain a vector clock $\mathit{Th}(i)$. For each mutex $y$, we find vector clock $\mathit{Rel}(y)$ to maintain the last release event on $y$. Initially, for each vector clock $\mathit{Th}(i)$ all time stamps are set to 0 but position $i$ where the time stamp is set to 1. For $\mathit{Rel}(y)$ all time stamps are set to 0.

To efficiently compare read and write events, we make use of epochs.

Definition 13 (Epoch)

Let $j$ be a thread id and $k$ be a time stamp. Then, we write $j\sharp k$ to denote an epoch.

Each event can be uniquely associated to an epoch. Take its vector clock and extract the time stamp $k$ for the thread $j$ the event belongs to. For each event this pair of information represents a unique key to locate the event.

Epochs are use to manage unsynchronized reads and writes. Like in the original FastTrack algorithm, we find a set $cr$ of unsynchronized reads where each read is represented by its epoch $j\sharp k$. In addition, we also maintain a set $cw$ of unsynchronized writes. This set serves the purpose to identify all HB write-write and write-read race pairs and to build up the edges for WRD candidates. Race pairs are recorded in $races$ and edges in the set $edges$.

We consider the various cases. In case of an acquire event we synchronize the thread’s vector clock with the most recent release event by building the union of the vector clocks $\mathit{Th}(i)$ and $\mathit{Rel}(x)$. In case of a release event, we update $\mathit{Th}(x)$.

Each write event compares the epochs in $cw$ against the thread’s vector clock. The condition $k>\mathit{Th}(i)[j]$ (line 3) indicates that the write is concurrent to the current epoch (event) in $cw$ and therefore a new write-write race pair is added to $races$. All data race pairs are represented via their epochs. We update the set $cw$ (line 7) and only keep writes in $cw$ that are concurrent. For each concurrent read in $cr$ we add a write-read race pair (line 11). For each WRD candidate of read, we add a new edge (line 10). This step corresponds to the construction in Definition 11).

By updating $cw$ (line 7) we include an optimization. We only maintain WRD candidates that are unsynchronized with respect to each other. We know candidates in $W_{1}$ are unsynchronized with respect to each other. The same applies to $W_{2}$. However, it is possible that $f\in W_{1}$ and $g\in W_{2}$ where $g<^{\scriptscriptstyle HB}f$. Due to space limitations, we refer to Appendix 0.A.1 for an example. Event $g$ can be safely omitted, because any WRD relation introduced by $g$ is covered by $f$.

The treatment is similar for read events. We assume that for events appearing in the same thread, we add an edge to the set $edges$ if they appear one after the other (in that thread). For brevity, we omit the details.

Example 4

We consider a run of the SSHB algorithm by processing the following trace. We underline events for which a new race pair is detected. The subscript is the vector clock for each event. The set $\{1\sharp 1\}_{x}$ in column $cw$, depicts the set $cw$ for variable $x$. Similarly for column $cr$, $\{2\sharp 1\}_{x}$ depicts the set $cr$ for variable $x$.

[TABLE]

The read in the second step is concurrent to the write in the first step. This is detected by comparing the epochs in $cw_{x}$ with the vector clock of thread two. Since the read is concurrent to the write, a new edge is added in the graph from the write to the read event (edge 1).

The same applies to the write in the fourth step. It is concurrent to the read in step 2, thus a new data race pair is created and a edge is added in the graph (edge 3).

At step five we create the next race pair between the events $2\sharp w(y)$ and $3\sharp w(y)$. In the first phase all write-read dependencies are ignored. Thus the two writes on $y$ are concurrent. This race pair is a false positive since a write-read dependency exists under which the events are ordered.

In the post processing phase the detected data race pairs $(1\sharp w(x),2\sharp r(x))$, $(2\sharp r(x),3\sharp w(x))$ and $(3\sharp w(y),2\sharp w(y))$ are tested.

For the first two data race pairs we omit the trivial path that exists due to the write-read dependencies in the implementation. We do not find an alternative path between the events without the direct write-read dependency edge and thus report a guaranteed data race for both data race pairs.

For the data race pair $(3\sharp w(y),2\sharp w(y))$ we find a path from event $3\sharp w(y)$ to $2\sharp w(y)$ by following edge two, three and four. Thus the race pair is categorized as maybe.

We consider the space and time complexity of running Algorithm 1. We assume $n$ to be the size of the trace and $k$ to be the number of threads. The size of $cr$ and $cw$ is bound by $O(k)$ and the size of $races$ and $edges$ is bound by $O(n*n)$. We assume the addition and removal of elements to any of the sets takes time $O(1)$. For write, there are $O(k)$ elements to consider. The same applies to read. The update of a vector clock takes time $O(k)$. So, processing of each event takes time $O(k)$. Hence, the running time is $O(n*k)$.

The diagnostic analysis phase then checks for each write-write data race pair $(i\sharp k,j\sharp k^{\prime})\in races$ if there is path among $i\sharp k$ and $j\sharp k^{\prime}$ in the graph derived from $edges$. No path guarantees the race (see Proposition 5 ) whereas some path means ‘maybe’ (see Proposition 6 ). The time complexity is $O(n*n+n)=O(n*n)$ to check if a path exists. There are $O(n*n)$ race pairs. So, overall the time to check if races are guaranteed or maybe races is $O(n^{4})$. In practice, we experienced no performance issues as the worst case never arises.

The implementation can detect write-read and read-write data race pairs. A read and write event are in a guaranteed data race if there is no path between the events when omitting the write-read dependency edge that connects them.

[TABLE]

6.2 Experimental Results

For benchmarking we use two Intel Xeon E5-2650 and 64 gb of RAM with Ubuntu 18.04 as operating system. We use tests from the Java Grande Forum [26] and from the DaCapo (version 9.12, [4]) benchmark suite. All benchmark programs are written in Java and use up to 58 threads. Details for each benchmark can be found in Table 1. Column Events contains the length of the trace. Columns Threads, Vars and Lock describe the total number of threads, variables and mutex that were used in the observed schedule. Columns Reads, Writes and Syncs describe the kind of events that are stored in the trace (except fork/join events).

We compare our algorithm SSHB and its diagnostic (post-processing) phase against variants of FastTrack and SHB. FastTrack and SHB only report code locations that are in a race. Hence, we consider some variants of FastTrack, referred to as HBP, and SHB, referred to as SHBP, that report pairs of events that are in a race. We ignore pairs that refer to the same source code locations.

[TABLE]

For HBP and SHBP we report the overall processing time in seconds (s) which includes parsing the trace, running the algorithms etc. The number 0 means that the time measured is below 1 second. We make use of an extension of RoadRunner for creating a log file of all trace events. Our algorithms are implemented in Go, therefore, we need to apply some transformations that creates some extra overhead. In the first row, labeled with the algorithm name, we present the time in seconds of the complete run including parsing the trace, race prediction and reporting. The row labeled #Races shows the amount of predicted data race pairs. We only report and count unique code location pairs. Race pairs are additionally categorized in read-write, write-read and write-write data races. The row #Read-write represents the case that the read appeared before the write in the trace, whereas #Write-read represents the case that the write appeared first.

For SSHB we separately measure the time to run Algorithm 1 (first phase) and to check for guaranteed/maybe data races in the (second) diagnostic phase. See row labeled Phase1 + 2 (s). We present the number of races reported in the first phase and the number of guaranteed races obtained via the (second) diagnostic phase. For example, for the moldyn benchmark we find in row #Races/G the entry 45/6 which indicates 45 race pairs in the first phase of which are 6 guaranteed races. The leading number, here 45, always coincides with the number reported by HBP. We also report the average and maximum size of the set of WRD candidates via #w(r)(Avg) and #w(r)(Max). Table 2 shows the result for each benchmark.

Guaranteed data races are likely to be the more ‘critical’ races and are not influenced by inaccurate tracing. Consider the tomcat benchmark. HBP reports 1322 data races whereas SHBP still reports 662. Recall that SHBP imposes a fixed write-read dependency based on the order of writes/reads in the trace. SSHB reports 194 guaranteed races by considering all possible WRD candidates due to inaccurate tracing. This is still a high number but it becomes more feasible for the user to trace down 194 races than 1322 or 662.

Based on the average number of WRD candidates, see row labeled $\#w(r)(Avg)$, we argue that imposing a fixed write-read dependency as done by SHBP may lead to inaccuracies. For example, for benchmark moldyn we find 1.72 WRD candidates and for benchmark avrora we find 1.65 WRD candidates on the average. This is another indication to focus on guaranteed races rather than any race.

For the benchmark moldyn we find a maximum of 6683 WRD candidates, see row labeled #w(r)(Max). The reason for this high number is that the associated read event has multiple data races with write events that result from the same code location. Recall that we only count the number of race pairs with distinct code locations. However, our graph captures all events regardless if they refer to the same code location. Hence, the significant difference between #w(r)(Max) and the number of races reported.

The traces for our benchmark programs are rather long. So, we did not inspect the traces to check for inaccuracies regarding unsynchronized reads and writes nor did we check if maybe races are false positives. For example, consider the avrora benchmark. HBP reports 36 races whereas SHBP reports 24 races. Our method SSHB reports that out of the 36 (24) there are 20 guaranteed races. To check that the 16 HBP races and 4 SHBP races are false positives, would require manual inspection of the specific program run as well as detailed knowledge of the program text.

To summarize. We observe that across all benchmarks there is a difference between the number of races and the number of guaranteed races. Furthermore, the max number of WRD candidates, see #w(r)(Max), is besides the raytracer and lusearch benchmark fairly high. Hence, it is likely that some traces are inaccurate. Our method identifies guaranteed races and thus allows the user to focus on ‘critical’ races.

6.3 Impact of RoadRunner on Results

In our experiments, we use the RoadRunner version from https://github.com/stephenfreund/RoadRunner. For this version, acquire and release events are issued after the respective operation has executed. Then, guarantee INST_RA, see Section 3, no longer holds and we may encounter false positives among the guaranteed races reported by SSHB.

Recall the example in Figure 1. The release event is only issued after the actual operation. There is some subsequent acquire operation that takes place in some concurrent thread. As the resulting acquire event is issued concurrently to the release event, the acquire event might appear before release in the trace. In our example, $\mathit{acq}(y)$ appears at trace position $3$ and $\mathit{rel}(y)$ appears at trace position $5$. When deriving the happens-before relation based on the inaccurate trace, the two write events at trace position $2$ and $4$ are unordered. Hence, we predict a write-write data race. This is wrong as both writes are mutually exclusive to each other. Hence, among the guaranteed races reported by SSHB, there may be still some false positives due to inaccurate release-acquire dependencies.

Adapting RoadRunner by following the instrumentation scheme outlined in Definition 2 would fix the issue of inaccurate release-acquire dependencies. However, this turned out to be difficult and therefore we decided for another option. We use the original RoadRunner version. For each guaranteed data race report, we apply a check to filter out false positives due to inaccurate release-acquire dependencies. This check is rather simple and is carried out via the lockset algorithm [7].

The lockset algorithm tries to determine if a variable is always protected by the same mutex. If it cannot determine at least a single mutex that is always used, it reports a potential data race for this variable and its accesses. For this, every thread maintains a set of mutex that it currently owns. For each acquire event the mutex is added to the lockset of the thread. For every release event the mutex is removed from the set.

The important insight is that the lockset algorithm is is not affected by inaccurate release-acquire dependencies. This is so because for computing the lockset in each thread, we only care about inter-thread acquire-release dependencies. To check if guaranteed races are affected by inaccurate release-acquire dependencies, we run the lockset algorithm simultaneously with our SSHB algorithm. We flag a guaranteed data race reported by SSHB as a false positives, if the intersection of the locksets of the events involved in the race is non-empty.

In Figure 6 we revisit the earlier example that explains the problem of inaccurate release-acquire dependencies (Figure 1). For this example we find that both threads own mutex $y$ when they access variable $x$. Hence, the intersection of the locksets of both writes is non-empty. Hence, lockset does not report a data race as a common mutex for all accesses on $x$ exists. On the other hand, SSHB reports a guaranteed data race that involves both writes. Based on the information provided by the lockset algorithm, we identify this guaranteed race as a false positive.

Table 3 shows how many guaranteed data races reported by SSHB are identified as false positives due to inaccurate release-acquire dependencies. Benchmarks lusearch, tomcat, avrora and h2 are affected by this tracing inaccuracy. For example, in case of avrora six out of 20 reported guaranteed data races have a non-empty lockset and are therefore false positives.

7 Related Works

7.1 Instrumentation and Tracing

The RoadRunner tool by Flanagan and Freund [9] is used by numerous data race prediction methods. RoadRunner relies on the ASM code manipulation tool by Bruneton, Lenglet and Coupaye [5]. As discussed in Section 6.3, acquire and release events are issued after the respective operation has executed. Then, tracing of release-acquire dependencies may be inaccurate and false positives as described by the example in Figure 1 may arise. A further source of inaccurate tracing are unsynchronized reads/writes. There is no guarantee that their order as found in the trace is accurate and corresponds to an actual program run.

Marek, Zheng, Ansaloni, Sarimbekov, Tům and Qi [18] present the DiSL framework for instrumentation of Java bytecode. The objectives of DiSL are similar to RoadRunner. As we have learnt [2], DiSL could be adapted to accurately capture release-acquire dependencies. This would require two instrumentation runs. The first run instruments all instructions that need a post-instrumentation including the acquire instructions. Release instructions are instrumented separately in the second run where the instrumentation needs to be added before the release instruction to capture release-acquire dependencies correctly. To our knowledge, accurate tracing of write-read dependencies is beyond the capabilities of DiSL.

Kalhauge and Palsberg [15] implement their own instrumentation based on ASM instead of using RoadRunner. This is necessary as for the purpose of deadlock prediction they need to trace acquire operations that may be potentially being executed. Recall that RoadRunner only issues a trace event after acquire executes.

RVPredict [22] is a commercial tool suite that supports dynamic data race prediction and comes with its own tracing tool. We do not know if (and how) the issue of inaccurate tracing is addressed by RVPredict.

Cao, Zhang, Sengupta, Biswas and Bond [6] study the issue of efficient tracking of dependencies in a parallel run-time setting. They rely on a managed run-time, the Jikes R(esearch)VM [13], and employ thread-local traces to reduce the online tracking overhead. Their method appears to capture accurately write-read dependencies but this is not further explored as for data race prediction they only consider FastTrack which ignores write-read dependencies.

Hardware-based tracing [24] is more accurate and incurs a much lower run-time overhead compared to the software-based instrumentation schemes mentioned above. However, as there is only a limited amount of debug registers available to store events, the program behavior cannot be recorded continuously. Hence, we may miss events and this means the analysis is less accurate.

Sheng, Vachharajani, Eranian, Hundt, Chen and Zheng [24] introduce a tracing framework where two tracers are used together. The first tracer is the hardware tracer to record memory accesses. The second tracer is a standard software instrumentation to record acquire/release operations This leads to inaccuracies (release-acquire dependencies) in the trace but is compensated by lockset algorithm. Both traces need to be merged for further analysis. The merged trace contains potential inaccuracies as the exact timing among acquire/release and write/read operations may be not exact.

7.2 Happens-Before Based Data Race Prediction

Mathur, Kini and Viswanathan [19] observe that standard happens-before based methods such as FastTrack [8] are only sound up to the first race predicted. Subsequent races reported may be inaccurate (false positives). Mathur et. al. propose SHB, a happens-before based data race predictor that takes into account write-read dependencies and thus avoids false positives reported by FastTrack. The accuracy of SHB relies on the accuracy of traces. Recall the examples from Section 2.

The happens-before based data race prediction methods by Huang, Meredith and Rosu [11] and Kalhauge and Palsberg [15] additionally trace the values read and written to variables and include control flow events like if-conditions and while-loops (branch-event). The motivation is to explore more feasible trace reorderings. Inaccurate results due to inaccurate trace may arise. Due to space limitations, we refer to Appendix 0.E.

Biswas, Cao, Zhang, Bond and Wood [3] use sampling to reduce the run-time overhead. There is clearly a loss of precision (accuracy) which they are willing to trade in for improved run-time performance.

Huang and Rajagopalan [12] study the issue of incomplete trace in the data race setting. They propose a refined analysis method based on an SMT-solver to reduce the amount of false positives due to incomplete trace information. Programmer annotations are necessary to guide the solver in case of external functions that manipulate shared memory.

Wood, Cao, Bond and Grossman [30] consider how to reduce the synchronization overhead of online race predictors such as FastTrack. Wilcox, Flanagan and Freund [29] give a redesign of the FastTrack method to ensure that the resulting implementation is free of concurrency bugs. Both works do not address the issue of inaccurate tracing.

There are numerous other works that consider trace-based analysis methods to predict concurrency bugs. For example, consider [27, 23, 28]. To the best of our knowledge, the common assumption is that traces are accurate.

8 Conclusion

Happens-before based data race prediction methods rely on the accuracy of the trace of recorded events to guarantee that races are accurate. Unless some sophisticated and likely costly tracing method is used, e.g. consider [6], write-read dependencies recorded may not be accurate. We offer diagnostic methods to check if (1) a race is guaranteed to be correct regardless of any potential inaccuracies, (2) maybe incorrect due to inaccurate tracing. Our experimental results show that our methods adds value to existing data race predictors such as FastTrack and SHB. In future work, we plan to identify undetected races. Recall the example in Figure 3 where a race may be unnoticed due to inaccurate tracing.

Appendix 0.A Proofs

0.A.1 Auxiliary Results

Proposition 7

Let $T$ be a trace and $e$ be some read event. Let $f,g\in W_{1}(e)$ be two distinct write events. Then, $f$ and $g$ are unsynchronized with respect to each other.

Proof

Suppose $f,g\in W_{1}(e)$. By definition, there is no other write in between. Hence, $f$ and $g$ are unsynchronized with respect to each other. ∎

Proposition 8

Let $T$ be a trace and $e$ be some read event. Let $f,g\in W_{2}(e)$ be two distinct write events. Then, $f$ and $g$ are unsynchronized with respect to each other.

Proof

Suppose $f,g\in W_{2}(e)$. By definition, there is no other write in between. Hence, $f$ and $g$ are unsynchronized with respect to each other. ∎

Consider $f\in W_{1}(e)$ and $g\in W_{2}(e)$. Assuming $f<^{\scriptscriptstyle HB}g$ immediately leads to a contradiction. On the other hand, $g<^{\scriptscriptstyle HB}f$ is possible as shown by the following example.

Example 5

Consider the following trace.

[TABLE]

Consider the read event $r(x)_{10}$. We find $W_{1}=\{w(x)_{7}\}$ and $W_{2}=\{w(x)_{3}\}$ where $w(x)_{3}<^{\scriptscriptstyle HB}w(x)_{7}$.

0.A.2 Proof of Proposition 1

Proof

If the last write event $w$ as characterized by Definition 4 is unsynchronized w.r.t. the read $e$, then $w\in W_{1}(e)$. Otherwise, $w$ and $e$ are in happens-before relation. That is, $w<^{\scriptscriptstyle HB}e$. By the conditions in Definition 4 there is no other write (on the same variable) in between. Hence, $w\in W_{2}(e)$. ∎

0.A.3 Proof of Proposition 2

Proof

For each of the writes in one of the sets $W_{1}(e)$ and $W_{2}(e)$ applies the condition that there is no other write with the same property (happening) in between. Therefore, writes in $W_{1}(e)$ are unsynchronized with respect to the other. The same applies to $W_{2}(e)$. See Propositions 7 and 8. Hence, there cannot be more than $O(k)$ candidates to consider.

For both sets the worst-case number of candidates may arise as shown by the following example.

[TABLE]

We have that $W_{1}(r(x)_{13})=\{w(x)_{1},w(x)_{2}\}$ and $W_{2}(r(x)_{13})=\{w(x)_{4},w(x)_{7}\}$ where $k=5$. It is easy to generalize the example for arbitrary $k$. ∎

0.A.4 Proof of Proposition 3

Proof

We prove the statement by induction over the events in the trace.

Consider the case of a read event $e$. The write event chosen $f$ by WRD in Definition 4 is clearly an element in $W(e)$. If $f\in W_{2}(e)$ we are immediately done.

Consider the case that $f\in W_{1}(e)$. We need to show that by imposing $f<^{\scriptscriptstyle SHB}e$ we obtain a partial order. The only reason why this would not be the case is that there is some cyclic dependency. However, this is impossible as $<^{\scriptscriptstyle HB}$ and $<^{\scriptscriptstyle SHB}$ are built up by only considering events that appear earlier in the trace. That is, for two events $g_{1}$ and $g_{2}$ in $<^{\scriptscriptstyle HB}$ and $<^{\scriptscriptstyle SHB}$ relation we conclude that $\mathit{pos}(g_{1})<\mathit{pos}(g_{2})$ and therefore cycles are impossible. ∎

0.A.5 Proof of Proposition 4

Proof

For each read event $e$, we pick a candidate $f\in W_{2}(e)$. By assumption such a candidate $f$ always exists and enjoys the property $e<^{\scriptscriptstyle HB}f$. Hence, the relation $f<^{\scriptscriptstyle\exists SHB}e$ can already be derived via the HB relation. ∎

0.A.6 Proof of Proposition 5

Proof

Assume the contrary. Then, there would be a path. Contradiction. ∎

0.A.7 Proof of Proposition 6

Proof

We use the following notation. We will write $w,w^{\prime}$ for write events and $r,r^{\prime}$ for read events.

We assume a path exists. Nodes along the path are distinct. Hence, he label $W(r)$ appears at most once and we have that for each set $W(r)$ of WRD candidates we consider a specific choice.

We need to show that based on our choice of WRD candidates to built the path between $e$ and $f$, we can built a $<^{\scriptscriptstyle\exists SHB}$ relation that is a partial order. So, we need to consider the read events for which no WRD candidate has been chosen so far. We will show that there for the candidate-free read events $r$ we can choose a write candidate $w\in W_{2}(r)$. The resulting $<^{\scriptscriptstyle\exists SHB}$ relation is cycle-free and thus forms a proper partial order.

We consider the path where w.l.o.g. the path starts with $e$.

[TABLE]

We consider the situation that a specific candidate $w\in W(r)$ has been chosen to built this path. For the moment, we assume that $w\rightarrow r$ is the only non-HB edge (1). We further assume $w\in W_{1}(r)$. Otherwise, $w\in W_{2}(r)$. Then, Proposition 4 applies and we are immediately done. Hence, $w\in W_{1}(r)$ which implies that $w$ and $r$ are not in a $<^{\scriptscriptstyle HB}$ relation (2).

We consider a candidate-free read element $r^{\prime}$ where we pick $w^{\prime}\in W_{2}(r^{\prime})$. If there is no such $r^{\prime}$ we are immediately done. Suppose that adding the edge $w^{\prime}\rightarrow r^{\prime}$ creates a cycle. This means that $w^{\prime}$ must be part of the cycle. In particular, we conclude that

[TABLE]

The case that $w^{\prime}$ appears before $w$ immediately leads to a contradiction as we assume that $<^{\scriptscriptstyle HB}$ is a partial order and therefore cycle-free.

From above, we conclude that there is a HB path that contains a cycle. Recall our assumption (1). That is, $w^{\prime}\rightarrow\dots\rightarrow w^{\prime}$. This is clearly a contradiction. Hence, adding the edge $w^{\prime}\rightarrow r^{\prime}$ does not create a cycle.

We yet need to consider the situation that the candidate-free $r^{\prime}$ appears after $r$. As only HB edges are involved, we immediately conclude that adding the edge $w^{\prime}\rightarrow r^{\prime}$ does not create a cycle.

What remains is to generalize assumption (1). In case of multiple non-HB edges $w_{i}\rightarrow r_{i}$ we proceed by induction over the number of such cases by applying the above reasoning steps. ∎

Appendix 0.B FastTrack

Algorithm 2 shows an overview of the FastTrack algorithm from [8].

For each thread $i$ we maintain a vector clock $\mathit{Th}(i)$. For each variable $x$, we find a epoch $\mathit{L_{W}}(x)$ to maintain the last write access to $x$. Similarly, we find $\mathit{Read}(x)$ to maintain the concurrent read accesses. For each mutex $y$, we find vector clock $\mathit{Rel}(y)$ to maintain the last release event on $y$.

Initially, for each vector clock $\mathit{Th}(i)$ all time stamps are set to 0 but position $i$ where the time stamp is set to 1. For $\mathit{Read}(x)$, $\mathit{L_{W}}(x)$ and $\mathit{Rel}(y)$ all time stamps are set to 0. We write ${\sf inc}(V,i)$ as a short-hand for incrementing the vector clock $V$ at position $i$ by one.

We consider the various cases of Algorithm 2. For acquire and release events, parameter $i$ refers to the thread id and $x$ refers to the name of the mutex. Similarly, for writes and reads, $i$ refers to the thread id and x to the name of the variable.

In case of an acquire event we synchronize the thread’s vector clock with the most recent release event by building the union of the vector clocks $\mathit{Th}(i)$ and $\mathit{Rel}(x)$. In case of a release event, we update $\mathit{Th}(x)$.

In case of a write event we compare the thread’s vector clock against the read epochs in $\mathit{Read}(x)$ and the single write epoch stored in $\mathit{L_{W}}(x)$ to check for a write-read and write-write race. Then we update $\mathit{L_{W}}(x)$ to record the epoch of the most recent write on $x$. Last step is to increment the thread vector clock at position $i$ by one.

In case of a read event, we check for read-write races by comparing the thread’s vector clock against the last write epoch. The next step is to update the set of read epochs to contain only the concurrent reads.

Appendix 0.C HBP and SHBP Algorithms

Variants of FastTrack and SHB that report pairs of events that are in a race. See Algorithms 3 and 4.

Appendix 0.D Missed data races due to unique source code locations

Algorithms FastTrack, SHB and our variants ignore races that result from the same code location. Race pairs connected to the same code locations may be affected by different write-read dependencies. For example, consider conditional statements inside a loop. As our diagnostic phase does not distinguish between such race pairs and only consider race pairs based on their source location, we may miss some guaranteed data races as the following example shows.

For the following example code and trace the guaranteed data race on $x$ would be ignored. The first occurrence of the data race between the source code locations six in $Program1\sharp$ and five in $Program2\sharp$ is a false positive. The write read dependency on $y$ introduces a happens-before relation between the accesses on $x$. The second occurrence is a guaranteed data race since it does not have a write read dependency on $y$. The write read dependency only occurs for the first loop execution where $z=0$ applies. Repeated data races like the data race on $x$ are ignored in our benchmarks to reduce the amount of data races that need to be checked. Since the second occurrence is ignored, our algorithm will not report a data race for the writes on $x$. Testing all occurrences of data races would solve the problem but increases the time necessary to test the program.

[TABLE]

Appendix 0.E Value tracing

The works of [12] and [14] trace the values that are read and written for each read and write event. These extended traces potentially contain inaccuracies that influence the result of the race prediction. Consider the following two examples.

Example 6

In the following example we find two possible write-read dependencies that can not be distinguished by the value written and read on $x$. A data race is reported if the write-read dependency between step three and four is assumed. For the write-read dependency between step two and four, the accesses on $y$ are not in a race.

Example 7

Figure 7 shows how the code could be instrumented to obtain the values. We write $hash(x)$ for the evaluation of the value of $x$. The instrumentation introduces function calls ($trace_{w}$ and $trace_{r}$) that trace the write and read events and the associated values.

The function calls and the write/read events are not atomic, thus arbitrary delays between the actual write/read and the call to the tracing function can occur. In the following example the call $trace_{r}(x,hash(x))$ is delayed. Because of this delay, another thread is able to update the value of $x$ between the actual read and the function call.

The delayed $trace_{r}(xhash(x))$ call leads to the trace in Figure 8. According to the trace, the $3\sharp r(x,6))$ event reads the value six which is written by thread two at step three. A race prediction algorithm has to assume the write-read dependency between step three and four due to the traced values. Thus, a data race between step one and five is predicted.

In the actual execution, shown in Figure 7, the read event reads the value written by thread one. With the write-read dependency that occurred during the program execution, step one and five are not in a race.

Because of this inaccurate trace a false positive for the two accesses on $y$ is reported.

This is not limited to false positives. Figure 9 is similar to the previous example. The only change is that the write on $y$ is performed by thread two in this example.

Due to this change the data race on $y$ is not detected. A race prediction algorithm that only considers the write-read dependency, will always assume the write-read dependency between step six and three due to the value and discard the data race between step four and nine.

Appendix 0.F Tracing Error With RoadRunner

We recorded a run of the Tomcat test and additionally enumerated every lock and access event with a global access number to record the order in which they occurred. In the trace in Figure 10, the entry ‘1429007:1,WR,2657, JkMain.java:339:237,1423414’ is the 1429007. trace event, performed by thread one and it is a write event on variable 2657 at code location ‘Threadpool.java:661:12’. The access has 1423414 as its global access number that describes the order in which every memory access occurred.

In this example thread 24 acquires mutex 633 (2773. lock operation). It gets stuck trying to read variable 54437 as thread 1 first needs to write on variable 2657 (global access number for $1\sharp w(2657)<24\sharp r(54437)$. Thread 1 tries to acquire mutex 633 that thread 24 still owns and therefore is stuck too and cannot reach the write event on variable 2657 that is necessary for thread 24 to continue. Thus we have a cyclic dependency and are ‘stuck’ during our trace replay. Ignoring the order in which the memory access occurred leads to inaccurate write-read dependencies.