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

「コードレビューの視点 003」では、「マルチスレッドプログラミングに注意する」と題して、次のことが必要だと述べました。

• マルチスレッドプログラミングに関する基礎知識をすべてのソフトウェアエンジニアがきちんと習得していること
• 書かれたコードは、マルチスレッドプログラミングに関する豊富な知識と経験を持つ人がきちんとレビューをする
• 書かれたコードは、自動テストが実行できるようになっていて、様々なプラットフォーム（単一コアから複数コア、あるいは、マルチプロセッサー）で長時間ランニングテストを行う。さらに、同時にシステムに別の負荷（CPU、HDなどへの負荷）をかけたランニングテストも行う

そして、テストが止まっている場合には最優先デバッグすることも重要だと述べました。しかし、重要ことを書き忘れていました。デバッグは、テストが止まったままの状態でデバッガーをプロセスにアッタッチして行うということです。デバッグ文を入れてもう一度再現テストをして再現したらデバッグ文から推測するということではありません。

実際に止まっている状態で、すべてのスレッドがどこで待ちになっているのか、一体何が起きたのかを徹底して調査する必要があります。そうすると、コードレビューでは想定していなかったようなスレッドの動きが起きている場合あります。その時になって初めて、その動きが発生する可能性のある1つであることを認識できたりします。

手作業で製品テストを行うような開発では、どうしても、テスト部門（QA）はテスト項目の消化をスケジュール通りに行いためにシステムがハングすると、バグレポートを出して、リブートし残りのテストを行う傾向があったりします。

私自身が1993年から1996年に開発に従事したFuji Xerox DocuStation IM 200は、白黒ですがコピー/Fax機能に加えてペーパーユーザーインタフェースという機能を搭載したデジタル複合機でした。Solaris上にC++でマルチスレッドプログラミングしていました。テスト部門でのテストでハングした場合には、開発に連絡があり、調査を担当する開発者は自分の席からテスト部門の機器に接続して、デバッガーを立ち上げて調査をします。

基本的にデバッグして原因を解明するまでは、何時間でもデバッグを続けます。その間、テスターから「リブートして良いですか」と問い合わせがあるのですが、基本は「まだ待ってください」と答えてデバッグしていました。

2003年から2009年まで従事したプロジェクトでは、もっと大規模なシステムでマルチスレッドプログラミングを行っていたのですが、この時も、止まった状態でデバッガーで調査するのが必須でした（このプロジェクトは、私が過去に経験した最大規模のテスト駆動開発を行っていました）。

マルチスレッド設計・プログラミングによるシステムは、作り方によっては、一人、いや、複数のエンジニアの想像を超えたことが起きる場合があり、常に再現するとは限りません。したがって、止まった時にきちんとデバッグすることが必須です。そして、そのようにデバッグできる環境も含めて、開発環境を整備することが求められます。