Contents
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 process access the same memory location concurrently, 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. A data race may result in non-deterministic program behavior and incorrect execution. Bugs caused by data races are notoriously difficult to detect by hand. DRDT keeps track of data accesses in a multi-threaded program at runtime, and reports data races that have been encountered. By automatically detecting data races, the tool relieves the programmer from the laborious task of debugging the program and eases the task of multi-threaded programming. DRDT supports the following hardware and operating systems: A Getting Started Guide, and
a tutorial on Using DRDT
have been prepared for this
preliminary release. There is also a general
DRDT Information Page DRDT can detect data-races that occur in code that is written using the POSIX thread API, the Solaris Operating System(R) thread API, OpenMP directives, Sun parallel directives, Cray(R) parallel directives, or a mix of these. Not yet. DRDT currently only detects data-races between different threads spawned from a single process. No. DRDT detects data-races at run time and the exact run-time behavior of an application depends on the set of input data. A given input-data set may not lead to a data-race. DRDT models the concurrency between threads at a high level in order to minimize the impact of scheduling by the operating system. However, the operating system scheduling can still affect memory allocation and storage reuse which changes the potential for data-races. Use DRDT with different numbers of threads and with different input data-sets and repeat experiments with a single data set to maximize the tool's chance of detecting data-races. This occurs because of timing differences between runs. As the threads access memory in a different order from run to run, different data-race results will be reported. In some cases, DRDT may report data-races that never actually occur in the program. These are called false positives, which usually happen 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, DRDT will not recognize these synchronization points. Please see the tutorial on using DRDT for a detailed description of false positives and examples of how to remove them through user API calls. librdthooks.so is a library that satisfies the entry points for the data-race-detection instrumentation calls and user API calls. It is linked automatically when a program is compiled and linked with -xinstrument=datarace. See the librdthooks(3) man page for more information.
This is a known limitation of the current Express build. Use nm. See the nm(1) man page for more details. If you find a global undefined symbol of either __rdt_src_read or __rdt_src_write, then the executable or library is instrumented.
Yes, though the Analyzer displays all of the traditional performance
analysis tabs as well as the new Races, Race Source, and Race Detail
tabs. The
You are using an older version of Sun Studio that does not support
DRDT. Check the version of Sun Studio that you are using by typing:
cc -Version
You are using an older version of Sun Studio that does not support DRDT. Check the version of Sun Studio that you are using by entering er_print -V. You must use a version that is no older then June 2006. You are using an older version of Sun Studio that does not support DRDT. Check the version of Sun Studio that you are using by entering collect -V. You must use a version that is no older then June 2006. The best resource for sharing your feedback with the DRDT engineers and users is by reading and posting to the Sun Studio Tools forum. You may find that your question has already been answered.
(Last updated June 19, 2006)
| ||||
|
| ||||||||||||