1. What is the Thread Analyzer and What Does It Do?
3.2 Getting the Deadlock Tutorial Source Files
3.2.1 Source Code Listing for din_philo.c
3.3 The Dining Philosophers Scenario
3.3.1 How the Philosophers Can Deadlock
3.3.2 Introducing a Sleep Time for Philosopher One
3.4 How to Use the Thread Analyzer to Find Deadlocks
3.4.2 Create a Deadlock Detection Experiment
3.4.3 Examine the Deadlock Detection Experiment
3.4.3.1 Using Thread Analyzer to View the Deadlock Detection Experiment
3.4.3.2 Using er_print to View the Deadlock Detection Experiment
3.5 Understanding the Deadlock Experiment Results
3.5.1 Examining Runs That Deadlock
3.5.2 Examining Runs That Complete Despite Deadlock Potential
3.6 Fixing the Deadlocks and Understanding False Positives
3.6.1 Regulating the Philosophers With Tokens
3.6.1.1 A False Positive Report
3.6.2 An Alternative System of Tokens
You can use the Thread Analyzer to check for potential and actual deadlocks in your program. The Thread Analyzer follows the same “collect-analyze“ model that the Oracle Solaris Studio Performance Analyzer uses.
There are three steps involved in using the 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, may 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 options.
For this tutorial, compile the code using the following command:
% cc -g -o din_philo din_philo.c
Use the Thread Analyzer's 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
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 the Thread Analyzer, the Performance Analyzer, or the er_print utility. Both the Thread Analyzer and the Performance Analyzer present a GUI interface; the Thread Analyzer presents a simplified set of default tabs, but is otherwise identical to the Performance Analyzer.
To start the Thread Analyzer and open the din_philo.1.er experiment , type the following command:
% tha din_philo.1.er
The Thread Analyzer includes a menu bar, a tool bar, and a split pane that contains tabs for the various displays.
The following tabs are shown by default in the left-hand pane when you open an experiment that was collected for deadlock detection:
The Deadlocks tab
This tab shows a list of potential and actual deadlocks that the Thread Analyzer detected in the program. This tab is selected by default. 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.
The Dual Source tab
Select a thread in the circular chain on the Deadlocks tab and then click on the Dual Source tab. The Dual Source tab 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.
The Experiments tab
This tab shows the load objects in the experiment, and lists any error and warning messages.
The following tabs are shown on the right-hand pane of the Thread Analyzer display:
The Summary tab which shows summary information about a deadlock selected from the Deadlocks tab.
The Deadlock Details tab which shows detailed information about a thread context selected from the Deadlocks tab.
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.
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.