第 1 章 スレッドアナライザの概要とその機能

スレッドアナライザは、マルチスレッドプログラムの実行を解析するためのツールです。このツールは、POSIX スレッド API や Solaris OS(R) スレッド API、OpenMP 指令、Sun 並列指令、Cray(R) 並列指令、あるいはそれらの組み合わせを使用して記述されたコード内のデータ競合やデッドロックなどのマルチスレッドのプログラミングエラーを検出できます。

1.1 スレッドアナライザの使用

スレッドアナライザは、新しいコマンド tha を使用して起動できます。スレッドアナライザのインタフェースはマルチスレッドプログラムの解析用に簡素化されているため、従来のアナライザのタブは表示されません。代わりに、新しく「競合」、「デッドロック」、「デュアルソース」、「競合の詳細」、および「デッドロックの詳細」タブが表示されます。アナライザを使用して、同じマルチスレッドプログラムの実験を観察すると、これらの新しいタブとともに、「関数」、「呼び出し元 – 呼び出し先」、「逆アセンブリ」などの従来のアナライザのタブが表示されます。

スレッドアナライザは、次のハードウェアおよびオペレーティングシステムに対応しています。

• SPARC(R) v8plus、v8plusa、v8plusb、v9、v9a、v9b アーキテクチャー

• Intel(R) x86 および AMD(R) x64 プラットフォーム

• Solaris 9 および Solaris 10 オペレーティングシステム

• SuSE Linux Enterprise Server 9 および Red Hat Enterprise Linux 4 オペレーティングシステム

1.2 データの競合とは

スレッドアナライザは、マルチスレッドプロセスの実行中に発生するデータの競合を検出します。データの競合は次の場合に発生します。

• 1 つのプロセス 内の 2 つ以上のスレッドがメモリー上の同じ場所に同時にアクセスし、かつ

• そのアクセスの少なくとも 1 つが書き込みアクセスで、かつ

• どのスレッドも排他的ロックを使用して、そのメモリーへのアクセスを制御していない。

これら 3 つの条件が成立すると、アクセス順序が非決定的となり、アクセス順序により、実行のたびに演算結果が異なることがあります。害のない良性データ競合もありますが (たとえば、ビジー待ちのメモリーアクセスなど)、多くのデータ競合はプログラムのバグです。

スレッドアナライザは、POSIX スレッド API、Solaris スレッド API、OpenMP、Sun 並列指令、Cray 並列指令、あるいはそれらの組み合わせを使用して記述されたマルチスレッドプログラムに有効です。

1.3 デッドロックとは

デッドロックは、2 つ以上のスレッドが互いの待ち状態になり、永久にその実行が妨げられる (滞る) 状態を表します。デッドロックの原因は数多く存在します。スレッドアナライザは、相互排他ロックの不適切な使用によって発生するデッドロックを検出します。この種のデッドロックは、マルチスレッドアプリケーションでよく起きます。2 つ以上のスレッドを持つプロセスで、次の条件が成立すると、デッドロックになる可能性があります。

• すでにロックを保持しているスレッドが新しいロックを要求し、かつ

• それらの新しいロック要求の発生タイミングが同時で、かつ

• 2 つ以上のスレッドが、それぞれチェーン内で次のスレッドが保持するロックを待つ循環チェーンを形成している。

次に簡単なデッドロック状態の例を示します。

デッドロックは、潜在的デッドロックと実 デッドロックの 2 種類に分けることができます。潜在的デッドロックはプログラムを実行すると必ず発生するわけではなく、スレッドのスケジューリングやスレッドによるロック要求のタイミングによって、プログラムの実行時に発生する可能性があるデッドロックです。これに対し実デッドロックは、プログラムの実行中に発生するデッドロックです。実デッドロックでは、関係するスレッドの実行は滞りますが、プロセス全体の実行は滞ることもあれば、そうでないこともあります。

1.4 スレッドアナライザの用途モデル

次の手順は、スレッドアナライザを使用してマルチスレッドプログラムの障害を追跡するためのプロセスを示しています。

1. プログラムに計測機構を組み込みます。詳細は、「2.2.1 ソースコードへの計測機構の組み込み」を参照してください。

2. 実験を行い、入力データやスレッド数、ループスケジュールの変更、さらにはハードウェアを変更するなど、要素を変更しながら、実験を繰り返します。この繰り返しは、根本的な原因が不明な問題の発生場所の特定に役立ちます。

3. スレッドアナライザによって明らかにされたマルチスレッドプログラミングの問題が本物のバグか、または良性の現象かを判定します。

4. バグを修正し、実験を繰り返します。

5. スレッドアナライザから新しいマルチスレッドプログラミングの問題が報告された場合は、前述の 2 つの手順を繰り返します。