Maestro: Isolation, Agents, and Message-passing in .NET

Maestro: Isolation, Agents, and Message-passing in .NET

MaestroはErlangのような祖結合、メッセージ駆動型のマルチスレッドの仕組みを.NET上に構築するためのプロジェクトのようだ。

.NETのスレッドの仕組みはCLRの提供するマルチスレッドの機能とスレッドプールの機能に依存していてその基本はリソース共有型のマルチスレッディングとなる。

リソース共有型のマルチスレッディングの問題はリソース(メモリやディスクI/O)を共有するため、その共有リソースに対しアクセスをする場合ロックを掛けるのだが、このロックにより、他のスレッドでロック解除待ちが発生し、実際には他のスレッドので処理が行われず、並列性が阻害される。

このロック待ちによる並列性の阻害は同一時刻断面で多数のスレッドが動作するメニィコアの世界ではより深刻になる。（プロセッサやコア数が少ない場合には同一時刻断面で同時実行されるスレッド数が少ないので、ロック待ちによる並列性が阻害される確率は下がってくる。その代わりそもそもスレッドの割り当て待ちが増える。）

.NET Fx 4.0で追加されるParallelも実際にはこの部分には実質的な変更はせずに、クラスライブラリで従来のThreading名前空間のクラスを使ったプログラミングに比べプログラミングのコード量を減らしているに過ぎない。

そのため、多数のスレッドが同時実行される場合にはスレッドを密結合して共有リソース上の共有データを持ち合う今の方法よりも、スレッド間を祖結合にするために共有データをメッセージとしてスレッド間でやりとりする方法のほうが、スレッドの同時実効性が向上すると考えられる。

別にこれは今まで議論がなかったことでも計算幾科学上の議論がなかったことでもなく、OSのマルチプロセス環境ではかならず密結合型のマルチタスク機能と祖結合型のマルチタスク機能は提供されている。前者はよくある共有メモリを利用したプロセス間通信やRPCであり、後者はWindowsやOpen VMSに見られるメールスロットによるプロセス間通信にその思想を見ることが出来る。(Windowsのプログラマはみんな使ってないけどさ。)

祖結合の利点や特性については、今ある分散環境での祖結合(メッセージキュー)のソリューション（MS-MQ, IBM MQ)やErlangについて調べてみるとわかってくると思う。

また、PCベースのマルチプロセッサのアーキテクチャがNUMA化されている中で、迂闊に共有メモリを使う場合の実際のコストに関しても注意して行く必要があり、その点でメッセージパッシング方式の方がOSやランタイムで工夫できる余地が多い事についても考えていきたい。

という事で、安心した。（VS10/.NET 4の並列性機能の拡張でネイティブコードにメッセージ駆動型の並列機能のライブラリがあるのに.NETに無かったのが不満だった。）

ま、ようはプロセッサのクロックがあがらず、フリーランチが無くなり、メニィコアによって並列性が重要になる世界って言うのは、今まで巨大なマルチシステムのメインフレームやハイエンドのRSICプロセッサのサーバーでアプリケーションを作っていた一部のプログラマの苦悩や苦労を僕らも背負うことになるって事。