マルチスレッドについて（２）

　協調作業について考えてみることにしましょう。
現段階でのプログラミングでは、シングルスレッドプログラミングが主流です。ステート・チャート図に代表されるように、状態遷移を考慮してプログラムを組む事に慣れていても、協調作業には慣れていないという側面があると思います。

　スレッドを生成するという事は、同時に並行して作業を行うという事です。家を建築するにあたり、土台が完成しない事には、柱を立てる事ができません。プレハブであれば、１階・２階に関係なくパーツを組み立てる事ができるでしょうが、１階部分を先に設置しない事には２階部分を設置する事ができません。

　作業の進み具合によっては、待ち時間が発生してしまうのです。

　自分の作業を進めながら、相手が作業を完了したか確認するタイミングと度合いなどを考え(＝設計し)なければなりません。これが地味に難しい。

　通信系のAPIには、IO Completion port と呼ばれるものがあります。これが使いにくいAPI で、通信を指示（データを送信しろ・データを受信しろ）した後に、通信が完了した時のコールバック関数を登録するか、シグナルと呼ばれる信号機のようなハンドルを利用します。指示してから、完了するまでの間を有効に使えるでしょ？というAPIです。ところがもの凄い短時間に通信が完了してしまって、コンセプトをもって設計しないと、何もしようがありません…。

　単純な作業を任せるだけなら良いのですが、この作業が終わったら今度は、あいつ（スレッド）に違う作業をやらせて…などと、コラボレーションの規模を大きくすれば、それだけモデルも複雑になっていきます。場合によっては、協調作業を行うための指揮者（スレッド）を雇わなければならないでしょう。

　マルチスレッド・プログラミングにおいては、設計の段階で構想力が要求されます。

　マルチスレッド化する目的も考えてみましょう。

1. レスポンスを確保するためのマルチスレッド化
2. ＣＰＵの性能をフルに引き出すためのマルチスレッド化
3. セキュリィティを確保するためのマルチスレッド化（マルチプロセス、マルチマシン）
   

大きく分けると、この３つが挙げられると思います。２番目ばかりに目を向けて、カーネルに推移せずSpinCount 休眠する CriticalSection 命みたいに思う人が多いと感じますが、１・３番目の目的においては、カーネル・レベルまで処理が落ちて、スレッドの動作が完全に停止する「ゆとり」処理も悪くはありません。

・・・続く