Programming with POSIX threads

9月前半のテストが終了しました。まだ後半の方にも有るので、まだやっていない夏休みの課題をさささっと片付けてしまう事にしよう。それにしてもH木先生はいつテスト日程を決めてくれるのか(笑)
最近はpthreadを用いたthread pooling式のマルチスレッドサーバーアプリケーションと毎日のように格闘しています。pthreadを使うにあたり良い本は無いものかとある人に紹介して頂いたのがProgramming with POSIX threadsです。

この本では基本的なPosix threadの機能の説明とそれを使用する具体的なコードが載っているほか、実際にアプリケーションで使うであろうパターン(work queueを使用する形)のコード等が載っています。特にcancellation(あるスレッドから他のスレッドを止める)の話や、マルチスレッドからforkする時の注意点等は非常に興味深かったです。
しかしまぁこの本を読んだからといって、すぐにpthreadを用いたマルチスレッドアプリケーションが書けるかというと全然書けませんでした。やっぱり問題となるのはmutexです。こいつを使うと一気に複雑度が増してしまいます。
なので個人的にマルチスレッドアプリを書く場合に一番重要だと思うのは「如何にmutexの数を適切に調節するか」という点です。mutexが多すぎてもunlock忘れによるデッドロックに苦しむ事になるし、逆にmutexが少なすぎてもlockする範囲が広くなりすぎてパフォーマンスが極端に下がってしまいます。これじゃマルチスレッドにする意味がない。後は「スレッドの切り替えは考えうる最悪のタイミングで起こる」ってのを念頭に置くことでしょうか。
この辺のコツは「Chapter 8: Hints to avoid debugging」に載っていましたが、実際に組んでみると本当に実感出来てちょっと驚きました。著者の人も相当苦しめられているのだろうか…とちょっと親近感が湧いてしまいました。あと、サーバーを書くにあたってもいくつか注意点などがあったので自戒も込めてメモ。

• close忘れは徹底的にチェック

  /proc/pid/fdで開いてるfile descriptorの数が確認できるので単調増加していないか常にチェック。エラー処理の部分は特に忘れがち…。

• 永遠にread待ち

  clientからの要求をreadする時にタイムアウトを設定していないと、そのスレッドが永遠にブロックされてしまう。特に特別な処理をするためのスレッドを１つ立て、そこで通信をする場合には特に注意。

• メモリリーク

  メモリ使用量が単調増加していないかをチェック。

とにかく負荷をかけまくって検証する事が一番重要ですね。デッドロックもこれらの問題も再現率が低い事が有るので。高負荷状態で10時間に１回発生するバグとか追うのは本当にもうどうしていいのやら…。頼れるものはログぐらいしかない。
もうちょっとマルチスレッドアプリケーションを書くときのデバッグ手法やツール等が欲しいなぁと思う今日この頃です。Signal飛ばして各スレッドにバックトレースをはかせたりもしてみたのですが、glibcのbacktraceでは全然有効な情報が得られない…。まぁこの辺は研究の余地有り、といった感じです。

Similar Posts:

• GDB: Debugging programs with multiple threads
• PythonでBounded Buffer
• はてな合宿