The Data-Race Detection Tool (DRDT) detects data-races that occur
during the execution of a multi-threaded process.
A data-race occurs when:
- two or more threads in a single process access the same
memory location concurrently, and
- at least one of the accesses is for writing, and
- the threads are not using any exclusive locks to control their
accesses to that memory
When these three conditions hold, the order of accesses is
non-deterministic. Therefore each run can give different results
depending on the order of the accesses. Of course, some data-races may
be benign (for example, when the memory access is used for a busy-wait),
but many data-races are either bugs or caused by bugs in the program.
The Data-Race Detection Tool works on a multi-threaded program written
using the POSIX thread API, Solaris thread API, OpenMP, Sun parallel
directives, Cray parallel directives, or a mix of the above.
Please note that the Data-Race Detection Tool is still in the
development stage. The user model -- including instrumentation
requirements, command names, command options, output formats, and GUI
interface -- may change later in the product release cycle. Since the
tool is based on a development build, the compilers and tools may
contain bugs, and certain features may not work as described.
The Data-Race Detection Tool follows the same "collect-analyze" model
that the Sun Studio
Performance Analyzer uses.
There are three steps involved in using the tool:
- Instrument the source code
- Create a data-race-detection
experiment
- Examine the
data-race-detection experiment
These three steps are described below.
In order to enable data-race detection in a program, the source files
must first be compiled with a special compiler option. This special option
for each of C, C++, and Fortran is: -xinstrument=datarace
Add the -xinstrument=datarace compiler option to the existing
set of options you use to compile your program. You can apply the
option to only the source files that you suspect to have data-races.
It is recommended that you use no optimization level when compiling
your program for race detection. Compile an OpenMP program with
-xopenmp=noopt. The information reported, such as line numbers and
callstacks, may be incorrect when a high optimization level is used.
Examples:
cc -xinstrument=datarace t.c -mt source.c
cc -xinstrument=datarace t.c -xopenmp=noopt source.c
CC -xinstrument=datarace t.cc -mt source.cc
CC -xinstrument=datarace t.cc -xopenmp=noopt source.cc
f90 -xinstrument=datarace t.f90 -mt source.f90
f90 -xinstrument=datarace t.f90 -xopenmp=noopt source.f90
Use the collect command with the -r on flag to run
the program and create a data-race-detection experiment during the
execution of the process.
Example:
collect -r on ./a.out
A data-race-detection experiment can be examined with the
rdt command, the analyzer command, or the er_print
utility.
Both the rdt and the analyzer commands present a GUI
interface; the former presents a simplified set of default tabs, but
is otherwise identical to the analyzer.
The er_print utility, on the other hand, presents a
command-line interface. The subcommands that are generally useful for
examining races with er_print are:
races
Report any data-races detected in the experiment.
rdetail race_id
Display detailed information about the data-race with the specified
race_id. If the specified race_id is
"all", then detailed information about all data-races will be
displayed.
header
Display descriptive information about the experiment, and report any
errors or warnings.
Examples:
rdt test.1.er
analyzer test.1.er
er_print test.1.er
Print-friendly Version
