"HAMADA, Masaaki" <allchapters nifty.com> writes:

> で話をもどして、ActiveObjectですが、最近のGUIフレームワークの多くが
> 各GUIコンポーネントへの直接アクセスを許さずイベントループ経由で起動
> することを要求しますが、これはまさにActiveObjectモデルといえますね。
> 
> これによって次のメリットを享受できます。
> 
> - デットロックを始めとするMT(マルチスレッド)プログラミング特有の問題を
>   すべてなくせる
> - その結果MTセーフを実現するための、ときに過剰である排他処理が不要となり
>   そのオーバヘッドをがなくせて、かつコードもシンプルに
>   (排他処理が必要なところはメッセージのpost/popのところのみ)

個々のアクターの基本的な動作としてはたしかにデッドロックフリーですが、
「他からのレスポンスを待つ」ようなことをすると、やっぱりデッドロックは
生じ得るんじゃないでしょうか。

あとは、キューのサイズが有限だと、やっぱりデッドロックが…とか。

ただ、並行プログラミングをすっきりさせるモデルとしては私も有効だと思い
ます。キューの長さは有限(というか0)ですが、Minixもこんな作りで書いてあ
りましたよね。デバイスドライバやファイルシステムは、それぞれがメッセー
ジ処理ループを回るタスクとして。

> これをなるべく同期式の場合と同等に記述できるようにするにはどうしたら
> いいかを考えてみたところ、まず
> 
> - コンテキストを複数用意して、非同期呼び出しの後はそのコンテキストを
>   保存して別のコンテキストでメッセージループを回し直す
>   → non-preemptiveなスレッド(＝coroutine)があればよい
> - やがてレスポンスが返ればもとのコンテキストを復元して処理を継続させる
> 
> と考えました。つまりActiveObject自体はpreemptiveなスレッドでそれぞれ
> 並行動作するのですが、ActiveObjectの中身はnon-preemptiveなスレッド
> で並行動作するというモデルになります。

今月の「コンピュータ・ソフトウェア」に昔のABCL/1 (Actor Based
Concurrent Language)の論文が再録されています。

ABCL/1では、メッセージ送信に
・過去型(非同期)
・現在型(同期的: 2つの過去型メッセージ送信で実現)
・未来型(非同期に送信して、返答は他のオブジェクトへ送らせる: 過去型と
  現在型の組合せで実現)
の3つがあり、過去型に当たる非同期なものしかないActorより簡潔に記述でき
るということになっています。

ご参考になるかも知れません。

				前田敦司

--
ML: langsmith quickml.atdot.net
使い方: http://www.atdot.net/~ko1/quickml