前田です。
おかえりなさいませ。
検査は大丈夫でしたか?

At Fri, 4 Jun 1999 16:18:42 +0900,
Shin-ichiro Hara <sinara / blade.nagaokaut.ac.jp> wrote:
> |むしろ、Thread.stopで他に制御が移るのは当り前で、他に制御が移らな
> |かったら条件が満たされることもないと思うのですが。
> 
> Thread.stop で他に制御が移るのは当り前なんですが、そのとき
> 全く排他制御がなくなってますよね。それが気妙な気がしたんで
> す。どんな mutex にも lock がかかっていないので、何があって
> もおかしくない状態なわけです。それでうまく行くのかどうか。
> 直観的にヤバそうな気がするのですが、、、

ここは任意のスレッドにロックを獲得するチャンスがないといけないの
で、ロックされてなくても大丈夫なんです。

で、条件が満たされた時に再獲得がなかなかできなくて困るということ
がないように、再獲得しようとしているスレッドは優先順位の高いキュー
に入れれられるようになっています。

> #と、いうことは条件変数を利用するプログラムはデッドロックを防ぐ
> #ためかなり注意が必要になるんだなあ。例えば [ruby-list:14445]の咳
> #さんの TinyQueue でいうと、wait を呼ぶのは
> #
> #      @full.wait(@mutex) if count == @max 
> #
> #と、
> #
> #      @empty.wait(@mutex) if count == 0 
> #
> #の２行だけれど、この count == @max と count == 0 が排他的な条
> #件だからうまく動いているのだと言える。そうでなければデッドロッ
> #クがありえる。

たしかにこの二つが競合すると典型的なデッドロックの例になってしま
いますね。

> monitor.rb をちょっと眺めたんですが、この難しさの半分は excludable に
> するための（石塚流？）メタプログラミングによるものですね。しかし、そこ
> を飛ばしてもやっぱり難しい。

アクセス制御をごちゃごちゃやらないで全部publicメソッドにするとも
う少しすっきりしそうな気もするのですけれどね...。

-- 
前田 修吾