第 7 章 コンパイルとデバッグ

この章では、マルチスレッドプログラムのコンパイルとデバッグについて説明します。

• マルチスレッドアプリケーションのコンパイル

• マルチスレッドプログラムのデバッグ

マルチスレッドアプリケーションのコンパイル

ヘッダファイル、定義フラグ、リンクなどについては、オプションが多数あります。

コンパイルの準備

マルチスレッドプログラムのコンパイルとリンクには、次のものが必要です。C コンパイラ以外は、Solaris オペレーティング環境に付属しています。

• 標準 C コンパイラ

• インクルードファイル

  • <thread.h> および <pthread.h>

  • <errno.h>、<limits.h> 、<signal.h>、および <unistd.h>

• 標準 Solaris リンカー、ln(1)

• Solaris スレッドライブラリ (libthread) と POSIX スレッドライブラリ (libpthread)。セマフォ用の POSIX リアルタイムライブラリ (librt) も必要な場合があります。

• 「MT-安全」ライブラリ (libc、libm、libw、libintl、 libnsl、libsocket、libmalloc、libmapmalloc など)

セマンティクスの選択 — Solaris または POSIX

一部の関数 (表 7–1 に示した関数など) は、POSIX 1003.1c 規格でのセマンティクスが Solaris オペレーティング環境 2.4 リリースでのセマンティクスと異なっています (後者は、より前の POSIX 草稿に基づいています)。関数の定義はコンパイル時に選択します。パラメータと戻り値の相違点については、『man pages section 3』を参照してください。

Solaris の fork(2) 関数はすべてのスレッドを複製しますが (汎用 fork 動作)、POSIX の fork(2) 関数は Solaris の fork1() 関数と同様、呼び出しスレッドのみを複製します (fork1 動作)。

<thread.h> または <pthread.h> の組み込み

インクルードファイル <thread.h> は、旧リリースの Solaris オペレーティング環境と上方互換性のあるコードをコンパイルするときに使用します (-lthread ライブラリとともに使用します)。このライブラリには両方のインタフェース、すなわち Solaris セマンティクスをもつインタフェースと POSIX セマンティクスをもつインタフェースが含まれています。POSIX スレッドで thr_setconcurrency(3THR) を呼び出すためには、<thread.h> を組み込む必要があります。

インクルードファイル <pthread.h> は、POSIX 1003.1c 規格で定義されているマルチスレッドインタフェースに適合するコードをコンパイルするときに使用します (-lpthread ライブラリとともに使用します)。POSIX 完全準拠を実現するには、定義フラグ _POSIX_C_SOURCE を下記のように 199506 以上の値 (long) に設定する必要があります。

	
cc [flags] file... -D_POSIX_C_SOURCE=N 	(ここで N  199506L)

Solaris スレッドと POSIX スレッドを同じアプリケーションの中で混用できます。それには、<thread.h> と <pthread.h> の両方を組み込み、-lthread と -lpthread のどちらかのライブラリとリンクします。

両者を混用した場合、コンパイルで -D_REENTRANT を指定し、リンクで -lthread を指定すると、Solaris セマンティクスが支配します。逆にコンパイルで -D_POSIX_C_SOURCE を指定し、リンクで -lpthread を指定すると、POSIX セマンティクスが支配します。

_REENTRANT または _POSIX_C_SOURCE の指定

POSIX 動作を望む場合は、-D_POSIX_C_SOURCE フラグで 199506L 以上の値を指定してアプリケーションをコンパイルしてください。Solaris 動作を望む場合は、-D_REENTRANT フラグを指定してマルチスレッドプログラムをコンパイルしてください。これは、アプリケーションのすべてのモジュールに当てはまります。 .

アプリケーションを混用する場合 (たとえば、Solaris スレッドを POSIX セマンティクスで使用する場合) は、-D_REENTRANT および -D_POSIX_PTHREAD_SEMANTICS フラグを指定してコンパイルします。

単一のスレッドのアプリケーションをコンパイルするときは、-D_REENTRANT も -D_POSIX_C_SOURCE フラグも指定しないでください。これらのフラグを指定しなければ、errno、stdio などの以前の定義がすべてそのまま効力を持ちます。

スレッドライブラリ (libthread.so.1 または libpthread.so.1) にリンクされておらず、-D_REENTRANT フラグが指定されていない、シングルスレッドのアプリケーションをコンパイルしてください。これによって、putc(3s) などのマクロが再入可能な関数呼び出しに変換されるときに生じる性能の低下が少なくなります。

要約すると、-D_POSIX_C_SOURCE が指定された POSIX アプリケーションは、表 7–1 に記載されているルーチンに関して、POSIX 1003.1c セマンティクスを持ちます。-D_REENTRANT のみが指定されたアプリケーションは、これらのルーチンに関して Solaris セマンティクスを持ちます。また、-D_POSIX_PTHREAD_SEMANTICS が指定された Solaris アプリケーションは、これらのルーチンに関して POSIX セマンティクスを持ちますが、Solaris スレッドインタフェースを使用することもできます。

-D_POSIX_C_SOURCE と -D_REENTRANT の両方が指定されたアプリケーションは、POSIX セマンティクスを持ちます。

libthread または libpthread とのリンク

POSIX スレッドの動作を望む場合は、-lpthread ライブラリをロードしてください。Solaris スレッドの動作を望む場合は、-lthread ライブラリをロードします。POSIX のプログラマでも、-lthread を指定してリンクすることにより、Solaris での fork() と fork1() の区別を維持したい場合があるでしょう。-lpthread を指定すると、fork() は Solaris の fork1() 呼び出しと同じ動作を行います。

libthread を使用するには -lthread を ld コマンドでは -lc の前、cc コマンドでは最後にそれぞれ指定してください。

Solaris 9 以前のリリースでは、スレッドを使用しないプログラムをリンクするときに、- lthread または -lpthread を指定しないでください。 指定すると、リンク時にマルチスレッド機構が設定され、実行時に動作してしまいます。これは、シングルスレッドアプリケーションの実行速度を低下させ、リソースを浪費し、デバッグの際に誤った結果をもたらします。

Solaris 9 以降のリリースでは、スレッドを使用しないプログラムをリンクするときに、-lthread または -lpthread を指定しても、意味上の違いは発生しません。これまでの単一スレッドで構成されたプログラムと同様に、余計なスレッドや LWP は作成されず、メインスレッドが唯一のスレッドとして実行されます。プログラムに対する唯一の影響は、システムライブラリのロックが空関数の呼び出しではなく本当のロックになるので、競合することのないロックを獲得する必要が生じることです。

図 7–1 は、コンパイルオプションを図解したものです。

図 7–1 コンパイルフローチャート

混用の場合は、thread.h と pthread.h の両方を組み込む必要があります。

リンクで -lthread も -lpthread も指定しないと、libthread と libpthread に対するすべての呼び出しが動作しなくなります。実行時ライブラリ libc には、libthread と libpthread 内の関数の仮エントリが NULL 手続きとして数多く定義されています。正しい手続きは、libc とスレッドライブラリ (libthread または libpthread) の両方がリンクされたときに、そのスレッドライブラリによって挿入されます。

スレッドを使用する C++ プログラムでは、アプリケーションをコンパイルしてリンクするには、-lthread ではなく オプションを使用します。-mt オプションは libthread とリンクし、ライブラリを適切な順序でリンクします。-lthread オプションを使用すると、プログラムがコアダンプすることがあります。

リンク時の POSIX セマフォ用 -lrt の指定

Solaris セマフォルーチン sema_*(3THR) は、libthread ライブラリに入っています。それに対し、標準的な POSIX 1003.1c セマフォルーチン sem_*(3R) を必要とする場合は、-lrt ライブラリを指定してリンクします (セマフォルーチンについては、セマフォを参照してください)。

新旧のモジュールのリンク

表 7–2 に、マルチスレッド化されたオブジェクトモジュールと、以前のオブジェクトモジュールをリンクする場合の注意事項を示します。

代替 libthread

Solaris 8 オペレーティング環境では、代替スレッドライブラリがディレクトリ/usr/lib/lwp (32 ビット) および /usr/lib/lwp/64 (64 ビット) に実装されました。 Solaris 9 オペレーティング環境では、このライブラリが /usr/lib および /usr/lib/64 に標準スレッドとして実装されています。

マルチスレッドプログラムのデバッグ

よく起こるミス

以下に、マルチスレッドプログラミングでよく起こるミスを示します。

• 呼び出し側のスタックへのポインタを新しいスレッドの引数として渡す。

• 広域メモリー (変更が可能で、かつ共有されている状態) をアクセスするときに同期機構で保護していない。

• 2 つのスレッドが異なる順序で、同じ組の広域リソースへの権利を獲得しようとしてデッドロックが発生する。この場合は、一方のスレッドが最初のリソースを獲得し、もう一方のスレッドが 2 番目のリソースを獲得し、どちらかがリソースを放棄するまで処理が進まなくなります。

• すでに保持しているロックを獲得しようとする (再帰的なデッドロック)。

• 同期機構の安全性に見えない間隙が生じている。これは、同期機構によって保護されているプログラム内で同期機構をいったん解除し、再度獲得してから戻る関数を呼び出していることが原因です。関数の呼び出し側から見ると広域データが保護されているようでも、実際には保護されていません。

• UNIX のシグナルとスレッドを組み合わせて使っている。非同期的なシグナルの処理には sigwait(2) を使用するほうがよいでしょう。

• setjmp(3C) と longjmp(3C) を使用し、相互排他ロックを解放せずにロングジャンプする。

• *_cond_wait() または *_cond_timedwait() の呼び出しから復帰した後、条件の再評価に失敗した。

• デフォルトスレッドを PTHREAD_CREATE_JOINABLE として生成した場合は、その記憶領域を pthread_join(3THR) で再利用しなければならないことを忘れている。なお、pthread_exit(3THR) は記憶領域を解放しません。

• 入れ子の深い再帰呼び出しを行なったり、大量の自動配列を使用したりする。マルチスレッドプログラムは、シングルスレッドプログラムよりもスタックの大きさの制限が厳しいので問題の原因となります。

• スタックの大きさの指定が適切でないか、デフォルト以外のスタックを使用している。

次の点にも注意してください。マルチスレッドプログラムの動きは、特にバグがある場合には、同じ入力で続けて実行しても再現性がないことがよくあります。

一般にマルチスレッドプログラムのバグは、決定的というよりも統計的な発生傾向を示します。このため実行レベルの問題を見つけるには、ブレークポイントによるデバッグよりもトレースの方が有効です。

TNF ユーティリティによる追跡とデバッグ

TNF ユーティリティ (Solaris システムの一部) は、アプリケーションとライブラリからの性能解析情報の収集、追跡、デバッグに使用します。TNF ユーティリティは、カーネルおよび複数のユーザプロセスとスレッドからの追跡情報を集約するので、マルチスレッドコードに特に有用です。

TNF ユーティリティを使用すると、マルチスレッドプログラムの追跡とデバッグが容易になります。prex(1)および tnfdump(1) の使用方法の詳細については、TNF ユーティリティのマニュアルページを参照してください。

truss(1) の使用

システム呼び出し、シグナル、およびユーザーレベル関数呼び出しの詳細については、truss(1) を参照してください。

mdb(1) の使用

以下の mdb コマンドを使用して、マルチスレッドプログラムの LWP にアクセスできます。

以下のコマンドは、条件付きブレークポイントを設定するためによく使用されます。

dbx の使用

dbx ユーティリティでは、C++、ANSI C、FORTRAN のソースプログラムをデバッグしたり、実行したりできます。dbx のコマンドは、デバッガと同じコマンドを受けつけますが、標準端末 (tty) インタフェースを使用する点が異なります。dbx とデバッガのどちらも、現在はマルチスレッドプログラムのデバッグをサポートしています。dbx とデバッガの詳細は、dbx(1) のマニュアルページおよび『Sun WorkShop 入門』を参照してください。

以下に示す表 7–5 にある dbx のオプションは、すべてマルチスレッドアプリケーションをサポートできます。