原です。

In message "[ruby-list:14828] Re: ConditionVariable (again)"
    on 99/06/05, Shugo Maeda <shugo / netlab.co.jp> writes:
|
|前田です。

|> 例えば Thread#run が一つも無くて、Thread#wakeup のみが使われている
|> こと。これも、スケジューリング問題の調整のためでしょうか。あとロッ
|> クの owner という概念があって、そこかしこに、owner がずれてると例外
|> を発生させる様になっているところとか。owner はカウントつきロックの
|> ためにだけあるのでは無いようですね。
|
|[ruby-list:6791]あたりにその辺の理由が書いてあります。
|簡単に言うとsignal/broadcastされた時点でwaitしたスレッドが優先的
|にロックを獲得できるようにするためです。

ええ、そうなっているのはわかります。しかしそんなことが必要になっ
てしまうのは signal で run させずに wakeup させているからですよ
ね。私の cv2.rb みたいに run させればいいだけのことではないかな
あ。なぜ run させずに wakeup & pass させるのだろう。

|あと、wakeupを使っているのはスケジューリングが起こって欲しくない
|からですね。

ああ、ここでスケジューリングというのはスレッドのスイッチという意味
ですね。なぜスイッチしたらいかんのだろう。どうせ不定な時期にスイッ
チするんだからここで意図してスイッチを起こしてもいいようが気がする
のですが。

もしかして条件変数とはそういうものだから、というのが答かな。(^^;
signal は wait-stop しているスレッドを起こすのではなくて、起きる機
会を与えるだけなんだ、という約束があるとか？

いや、条件変数の signal が原因でスレッドのスイッチが起こらないよう
にできるなら、その方が気持ちいいとは思います。たかが変数ごときにス
ケジュールを変形されたくないという気持ちは分かります。

もしそういうことなら、signal の頭で Thread.critical の値を保存し
て、最後にそれを復活させる（そして Thread.pass もさせない）という
のが徹底していて、いい様な気もします。


|> まず monitor.rb コピー mon-test.rb を取ります。:-)
|> そして、253行目あたり、クリティカルセクションが終った所で pass さ
|> せます。
|(snip)
|> するとやはり dead lock が起こります。（Linux です。）
|
|う、手元のmonitor.rbの253行目はスクリプトの終わりになってます(^_^;
|なんかこの間バグを一つつぶしたような気がする(夢だったかも)ので
|ruby-1.3.4付属のもので試していただけませんか?

おおっ、新しい monitor.rb を見てみました。かなり分かりやすい。いま
まで難しい、難しいと言っていたのは、ruby-1.2.5 までの話です。なるほ
ど、組み込みクラスのインスタンスがインスタンス変数を持てる様になっ
たのは大きいですね！

で新しい monitor.rb では、つけいるすき間はなくなっていました。結局、
私の cv2.rb と骨格はほとんど同じなんだなあ、signal で wakeup させる
かrun させるかの違いを除けば。

時代は 1.3 だな。(^^)