JavaScript is required to for searching.
Skip Navigation Links
Exit Print View
Oracle Solaris Studio 12.3: Thread Analyzer User's Guide     Oracle Solaris Studio 12.3 Information Library
search filter icon
search icon

Document Information

Preface

1.  What is the Thread Analyzer and What Does It Do?

2.  The Data Race Tutorial

3.  The Deadlock Tutorial

3.1 About Deadlocks

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 1

3.4 How to Use the Thread Analyzer to Find Deadlocks

3.4.1 Compile the Source Code

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

A.  APIs Recognized by the Thread Analyzer

B.  Useful Tips

3.4 How to Use the Thread Analyzer to Find Deadlocks

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:

3.4.1 Compile the Source Code

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

3.4.2 Create a Deadlock Detection Experiment

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.

3.4.3 Examine the Deadlock Detection Experiment

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.

3.4.3.1 Using Thread Analyzer to View the Deadlock Detection Experiment

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 following tabs are shown on the right-hand pane of the Thread Analyzer display:

3.4.3.2 Using er_print to View the Deadlock Detection Experiment

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:

Refer to the collect(1), tha(1), analyzer(1), and er_print(1) man pages for more information.