You can use Thread Analyzer to check for potential and actual deadlocks in your program. Thread Analyzer follows the same collect-analyze model that Oracle Developer Studio Performance Analyzer uses.
There are three steps involved in using Thread Analyzer:
Compile the source code.
Create a deadlock-detection experiment.
Examine the experiment results.
Compile your code and be sure to specify –g. Do not specify a high-level of optimization because information such as line numbers and call stacks, might be reported incorrectly at a high optimization level. Compile an OpenMP program with –g –xopenmp=noopt, and compile a POSIX threads program with just –g –mt.
See cc(1), CC(1), or f95(1) man pages for more information about these compiler options.
For this tutorial, compile the code using the following command:
% cc -g -o din_philo din_philo.c
Use the collect command with the –r deadlock option. This option creates a deadlock-detection experiment during the execution of the program.
For this tutorial, create a deadlock-detection experiment named din_philo.1.er using the following command:
% collect -r deadlock -o din_philo.1.er din_philo
The collect –r command accepts the following options, which are useful when creating a deadlock-detection experiment:
If an unrecoverable error is detected, terminate the program.
If an unrecoverable error is detected, terminate the program with a core dump.
If an unrecoverable error is detected, enable the program to continue.
The default behavior is terminate.
You can use any of the previous options with the collect –r command to get the behavior you want. For example, to cause the program to terminate with a core dump when an actual deadlock occurs use the following collect –r command.
% collect -r deadlock, abort -o din_philo.1.er din_philo
To cause the program to hang when an actual deadlock occurs, use the following collect –r command:
% collect -r deadlock, continue -o din_philo.1.er din_philo
You can increase the likelihood of detecting deadlocks by creating several deadlock-detection experiments. Use a different number of threads and different input data for the various experiments. For example, in the din_philo.c code, you could change the values in the following lines:
13 #define PHILOS 5
14 #define DELAY 5000
15 #define FOOD 100
You could then compile as before and collect another experiment.
See collect(1) and collector(1) man pages for more information.
You can examine a deadlock-detection experiment with Thread Analyzer, Performance Analyzer, or the er_print utility. Both Thread Analyzer and Performance Analyzer present a GUI interface; Thread Analyzer presents a simplified set of default views, but is otherwise identical to Performance Analyzer.
To start Thread Analyzer and open the din_philo.1.er experiment, type the following command:
% tha din_philo.1.er
Thread Analyzer has a menu bar, a tool bar, and vertical navigation bar on the left that enables you to select data views.
The following data views are shown by default when you open an experiment that was collected for deadlock detection:
Overview screen shows the metrics overview of the loaded experiments.
Deadlocks view shows a list of potential and actual deadlocks that Thread Analyzer detected in the program. The threads involved for each deadlock are shown. These threads form a circular chain where each thread holds a lock and requests another lock that the next thread in the chain holds.
When you select a deadlock, the Deadlock Details window in the right panel shows detailed information about the threads involved.
Dual Source view shows the source location where the thread held a lock, and the source location where the same thread requested a lock. The source lines where the thread held and requested locks are highlighted. To display this view, select a thread in the circular chain on the Deadlocks view and then click on the Dual Source view.
Experiments view shows the load objects in the experiment and lists any error and warning messages.
You can choose to see other views with the More Views options menu.
The er_print utility presents a command-line interface. You can use the er_print utility in an interactive session and specify sub-commands during the session. You can also use command-line options to specify sub-commands non-interactively.
To display the deadlock-detection experiment, type the following command:
% er_print din_philo.1.er
The following sub-commands are useful for examining deadlocks with the er_print utility:
–deadlocks
This option reports any potential and actual deadlocks detected in the experiment. Specify deadlocks at the (er_print) prompt or –deadlocks on the er_print command line.
–ddetail deadlock-ID
This option returns detailed information about the deadlock with the specified deadlock-ID. Specify ddetail at the (er_print) prompt or –ddetail on the er_print command line. If the specified deadlock-ID is all, then detailed information about all deadlocks is displayed. Otherwise, specify a single deadlock number such as 1 for the first deadlock.
–header
This option displays descriptive information about the experiment and reports any errors or warnings. Specify header at the (er_print) prompt or –header on the command line.
Refer to the collect(1), tha(1), analyzer(1), and er_print(1) man pages for more information.