B.4 Reporting of Data Races

Tips for reporting of data races:

• The Thread Analyzer detects data races at runtime. The runtime behavior of an application depends on the input data set used and operating system scheduling. Run the application under collect with different numbers of threads and with different input data sets. Also repeat experiments with a single data set to maximize the tool's chance of detecting data races.

• The Thread Analyzer detects data races between different threads that are spawned from a single process. It does not detect data races between different processes.

• The Thread Analyzer does not report the name of the variable accessed in a data race. However, you can determine the name of the variable by inspecting the source lines where the two data race accesses occurred, and determining which variables are written to and read from on those source lines.

• In some cases, the Thread Analyzer might report data races that did not actually occur in the program. These data races are called false positives. This usually happens when a user-implemented synchronization is used or when memory is recycled between threads. For example, if your code includes hand-coded assembly that implements spin locks, the Thread Analyzer will not recognize these synchronization points. Insert calls to Thread Analyzer user APIs in your source code to notify the Thread Analyzer about user-defined synchronizations. See 2.5 False Positives and Appendix A, APIs Recognized by the Thread Analyzer for more information.

• Data races reported using source-level instrumentation and binary-level instrumentation might not be identical. In binary-level instrumentation, shared libraries are instrumented by default as they are opened, whether they are statically linked in the program or opened dynamically by dlopen(). In source-level instrumentation, libraries are instrumented only if their sources are compiled with -xinstrument=datarace.