デバッグのための状態問い合わせストリームというものがある. これは全てのプロセスを串刺しにしたストリーム(図 2.6)で, これをプロセス・ネットワークに組み込んでおき, デバッグ時にこのストリームを通して各プロセスの状態をかき集めてデバッグ に役立てるものである.
次に, プロセス・ネットワークの使い方の面白い例を一つ挙げよう.
最適経路問題とは, 図 2.7のようなノード間をつないだコストつき
経路網が存在する時に, 開始点から終了点までの経路のうち,
コスト最小のものを求めるという, 探索問題の一つである.
探索問題であるから, これを部分問題に分割して,
各部分問題にプロセスを割り当てて, というように今まで述べてきた考え方
に沿って問題を解いていくこともできるのだが, もっと直接的かつ大胆に,
経路上の各ノードをプロセス, ノード間のアークを双方向ストリーム
, として
解くことも出来る.
各ノードプロセスは自分から伸びているアークのコストを知っている.
また, 各ノードはそれまでに判明した, 開始点から自分までの最適(コスト最小)経路
とそのコストの対を保持している.
そして, それよりも低コストな, 新たな自分までの最適経路を見つけた場合は
その新た最適経路とコストの対でもって保持している対を更新し,
自分に直接継っているノードにその新たな対をメッセージとして送る.
例えば, ノードfがある時点で, 自分までの最適経路がコスト7+2=9の
経路a
b
fだと思っている(その対を保持している)とする.
そこへ, ノードjから "ノードjまでの最適経路は
今のところa
e
i
jで, そのコストは
7だと分かった”という意味のメッセージ
{a
e
i
j,7} を受けとったら,
自分までの最適経路が今まで思っていたb回りの経路でなく, j回りの経路であ
ることが分かる. そこで, 保持している対をそのj回りのものに更新し,
ノードb, g, jに
メッセージ{a
e
i
j
f,8}
を送る. 開始点aがノードb,eにメッセージを送ることに始まって, このようなメ
ッセージがプロセス・ネットワーク上を流れ回った後には, 各ノードプロセスに
は開始点からそのノードまでの最適経路とそのコストの対が保持されている.
計算の終了は全てのメッセージがプロセス・ネットワークから消滅したことで
判定する(この判定は次章で述べるショートサーキットという技法が使われる
がここでは述べない).
