この節では, 他に提案されている種々の並列プログラムデバッグ環境[ 5, 8]と, 我々のシンボリックデバッガの関係について, 特に,その拡張について考察する.
まず,統合的なデバッグ環境との関連について. 我々のシンボリックデバッガでは, 各プロセッサ上にgdbをそれぞれ立ち上げ, その上でそのプロセッサ上での複数のスレッドが実行されている模様を トレースする物である. 一方,これらの複数の gdb を一つのプログラム上で管理し, 一つのデバッガとして扱うことも考えられる. このようなシステムの利点として, 特にremote operationのトレースの簡便性が挙げられる. 我々のシンボリックデバッガを,このようなシステムに拡張するのは容易である つまり,我々のシステムにおいて, remote operation の呼び出し側に達した時点で, 呼ばれる側のシステムで,実行要求がくるところにブレイクポイントを設定し, その到着をまてばよい.このとき,呼ばれる側のプロセッサ以外は 停止させておいて問題はない. また,他の gdb の機能に関しても,単純に該当プロセッサのgdbに 対してコマンドを発行すれば良い. 各プロセッサ上の gdb を単一プロセスで容易に扱える様な環境において有効で あると考える.
次は, 並列プログラムのデバッグに有効と考えられている再演機能 [ 7, 9]との関連に付いて. 再演機能と言うのは,あるプログラム実行に対して,ある種のログ情報をとることで, 全くおなじプログラム実行の再演を可能にするものである. 並列プログラムのデバッグが困難な理由の一つは 非決定性によるものであるといわれる. これは,並列プログラムにおいては スレッド間インタラクションの順序に任意性があるため, すなわち競合状況に起因して,その挙動は非決定的になる. このため,逐次プログラムのデバッグにおいて良く用いられている, cyclic debugging という手法を用いることができない. 再演機能を用いる事で, こういった問題を避けることができる.
我々が今回実装対象としていた分散メモリ並列計算環境において, StackThreadsのようなマルチスレッド実装を行った場合, [6] で提案している再演機構をもちいることができる. この方法では, 各ノードのスケジューラが決定的な挙動をしていると想定できる場合, ノード間通信の順序関係のみを保存することで 再演機構を実現している.
我々のシンボリックデバッガと再演機構の関連であるが, 再演機構の実現においては,C/C++ コード,ランタイムの改変は ノード間通信部に限定され,しかもランタイムとして隠蔽する事が出来る. このため,シンボリックデバッガには手を加えずに, 再演機構を付加させる事が出来る.
最後に,一般のカーネルスレッドなどを対象としたデバッガとの比較を行う. このようなデバッガは普通,スレッド毎に独立してその実行をトレースを行う. スレッド間に決まったスケジューリング順序は存在せず, デバッガの指定通りにそのシステムはその実行を行う事が出来る. 一方,StackThreads のようにスケジューラの挙動が決まっている システムにおいては,このような手法を用いる事が出来ない. つまり,ユーザが指定した順序でスレッドをスケジューリング,実行させる ことができない. つまり, 我々のシステムがユーザが指定した通りにスレッド実行を行うのではなく, スレッド実行の中でユーザが指定した場所のトレースを行うようになっているのは, 言語システムの性質に起因している. ユーザが指定した順序でスレッド実行を行えるようにするためには, 任意の時点ですきなスレッドの停止,再開を行えるよう, デバッグ時の言語ランタイムを拡張する必要がある.