The Thread Analyzer is a tool that you can use to analyze the execution of a multi-threaded program. It can detect multi-threaded programming errors such as data races or deadlocks 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.
You can start the Thread Analyzer by using the new tha command. The Thread Analyzer interface is streamlined for multi-threaded program analysis so it does not display the traditional Analyzer tabs. Instead, you see the new Races, Deadlocks, Dual Source, Race Details, and Deadlock Details tabs. If you use the Analyzer to look at the same multi-threaded program experiments you will see the traditional Analyzer tabs such as Functions, Callers-Callees, Disassembly, along with the new tabs.
The Thread Analyzer supports the following hardware and operating systems:
The SPARC(R) v8plus, v8plusa, v8plusb, v9, v9a, and v9b architectures
The Intel(R) x86 and AMD(R) x64 platforms
The Solaris 9 and Solaris 10 operating systems
SuSE Linux Enterprise Server 9, and Red Hat Enterprise Linux 4 operating systems
The Thread Analyzer 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, and the computation may give different results from run to run depending on that order. Some data-races may be benign (for example, when the memory access is used for a busy-wait), but many data-races are bugs in the program.
The Thread Analyzer 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.
Deadlock describes a condition in which two or more threads are blocked (hung) forever because they are waiting for each other. There are many causes of deadlocks. The Thread Analyzer detects deadlocks that are caused by the inappropriate use of mutual exclusion locks. This type of deadlock is commonly encountered in multi-threaded applications. A process with two or more threads can deadlock when the following conditions hold:
Threads that are already holding locks request new locks
The requests for new locks are made concurrently
Two or more threads form a circular chain in which each thread waits for a lock which is held by the next thread in the chain
Here is a simple example of a deadlock condition:
Thread 1 holds lock A and requests lock B
Thread 2 holds lock B and requests lock A
A deadlock can be of two types: A potential deadlock or an actual deadlock. A potential deadlock does not necessarily occur in a given run, but can occur in any execution of the program depending on the scheduling of threads and the timing of lock requests by the threads. An actual deadlock is one that occurs during the execution of a program. An actual deadlock causes the threads involved to hang, but may or may not cause the whole process to hang.
The following steps show the process by which you can troubleshoot your multi-threaded program with the Thread Analyzer.
Instrument the program. See 2.2.1 Instrument the Source Code for more information.
Perform an experiment and then repeat the experiment with varied factors such as different input data, a different number of threads, varied loop schedules or even different hardware. This repetition helps locate problems with non-deterministic roots.
Establish whether or not the multi-threaded programming-conflicts revealed by the Thread Analyzer are legitimate bugs or benign phenomenon.
Fix the legitimate bugs and repeat the experiment.
If the Thread Analyzer reports new multi-threaded programming-conflicts repeat the previous two steps.