Contents

1. Introduction
2. About the Sun Studio 12 Thread Analyzer (tha)
3. New and Changed Features
4. Software Corrections
5. Problems and Workarounds
6. Limitations and Incompatibilities
7. Documentation Errors

 

---

A. Introduction

Product Documentation

• Release Notes: Available at http://developers.sun.com/sunstudio/documentation/ss12/release_notes.html. Information in the release notes updates and extends information in all readme files.
• Compilers and Tools Documentation: You can access product man pages, HTML versions of readmes, and manuals from /installation_directory/SUNWspro/docs/index.html. The default installation directory is /opt. If your Sun Studio 12 compilers and tools are not installed in the default /opt directory, ask your system administrator for the equivalent path on your system.

   

  ---

  B. About tha

  The Thread Analyzer is new in this release of Sun Studio.

  The Thread Analyzer is a tool that analyzes the execution of a multi-threaded program and checks for a variety of multi-threaded programming errors such as data races and deadlocks.

  The tool can detect errors in code that is written using the POSIX thread API, the Solaris Operating System(R) thread API, OpenMP API, Sun parallel directives, Cray(R) parallel directives, or a mix of these.

  Data Races

  A data race occurs under the following conditions:

  • Two or more threads in a process concurrently access the same memory location,
  • At least one of the threads is accessing the memory location 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. Therefore each run can give different results depending on the order of the accesses. Some data races may be benign (for example, when the memory access is used for a busy-wait), but many data races are either bugs or caused by bugs in the program.

  Deadlocks

  Deadlock describes a condition where two or more threads are blocked (hang) forever, waiting for each other. Suppose we have a process with two or more threads. A deadlock occurs when the following three conditions hold:

  • Threads already holding locks request new locks,
  • The requests are made concurrently, and
  • Two or more threads form a circular chain where each thread waits for a lock that the next thread in the chain holds.
  Here is an example of a deadlock condition:

  Thread 1: holds lock A, requests lock B
  Thread 2: holds lock B, requests lock A

  A deadlock can be of two types: A "potential deadlock" or an "actual deadlock". A potential deadlock is a deadlock that did not occur in a given run, but can occur in different runs of the program depending on the timings of the requests for locks by the threads. An actual deadlock is one that actually occured in a given run of the program. An actual deadlock causes the threads involved to hang, but may or may not cause the whole process to hang.

  See the Thread Analyzer User Guide for details on how to use the Thread Analyzer.
  

   

  ---

  C. New and Changed Features

  This release of the Thread Analyzer includes the following features:

  • The new C, C++, and Fortran compiler option -xinstrument=datarace which instruments the source code during compilation. See tha(1) for more information.
  • User APIs to notify the Thread Analyzer of user-implemented custom synchronization schemes.
  • Command line and GUI tools interfaces to create an experiment and examine the results.

   

  ---

  D. Software Corrections

   

  ---

  E. Problems and Workarounds

  There are no problems or workarounds in this release.

   

  ---

  F. Limitations and Incompatibilities 

  The following are known limitations in the Thread Analyzer.

  • The Thread Analyzer can only detect data races in code that is instrumented at compile-time. You must recompile your code according to the instructions provided in the Thread Analyzer User Guide in order for it to be instrumented.
  • The Thread Analyzer is not able to recognize user-implemented synchronizations. It may report false positive data races if your code contains such synchronizations. For example, the Thread Analyzer does not recognize hand-coded assembly that implements spin locks as a synchronization point. Use the APIs described in libtha.3 to notify the Thread Analyzer of user-implemented synchronizations and thus avoid false positives.
  • Running programs under the Thread Analyzer can incur significant overhead depending on the nature of the application.
  • Asynchronous signal handling is not fully supported. Programs that use asynchronous signals may stall under the Thread Analyzer.

   

  ---

  G. Documentation Errors 

  There are no documentation errors to report

   

  ---

  Copyright © 2007 Sun Microsystems, Inc. All rights reserved. Use is subject to license terms.