[ruby-list:6773] Re: Mutex/ConditionVariable/Queue

  ついでに counting semaphore もあると, 並行プログラミングの実習に使え
  ますね (^^)

In message <[e-mail]>
[e-mail] (Yukihiro Matsumoto) writes:

> |Rubyのスレッドは全部同じ優先度で均等に実行される(ですよね?)ので
> |多分問題ないと思うのですが、実際のところどうなんでしょう。
> 
> 現状のrubyのスレッドに優先度が無いのは本当です．問題が無いか
> どうかは私には分かんないんです．すいません．

  疑問があるのですが....

    * ConditionVariable#signal で起きたスレッドは新たに mutex.lock を
      していますが, これって外から入って来るスレッドと優先度が同じです
      よね?

  「モニタで wait したスレッドが優先されるべきで, そうしないと wait し
  たスレッドが飢餓状態に陥る可能性がある」という話だったような気がする
  んですが. 大丈夫なんでしょうか? ちなみに broadcast でも同様.

  # waiter queue と signaler queue と entering queue があって, その優
  # 先度はとにかく entering queue が最低になる.

  # 「モニタの外にある状態変数って, わけわかんないからいまいち」という
  # 話と関連するんでしょうか?

    * ConditionVariable#signal をコールしたスレッド（以下 signaler）は
      そのまま走り続けるわけですが, signaler の実行で再び条件が満たさ
      れなくなった場合の対処はどのように考えるのでしょう?

  Signaler は signal したら寝てキューに入る, というのが普通みたいです.
  Signaler が寝ない場合には signal はどちらかと言うと `notify' という
  感じで, 起こされたスレッドがまた条件をチェックするようですが.

  # ....やっぱりモニタじゃなくて, 純粋に条件変数だ, ということだといら
  # ない?

  こないだの actor もどきと同じようにして monitor も作れそうなんですが, 
  何もやってません.... エントリプロシージャになるメソッドを除いて全部 
  private にするよりは actor とおなじようにアダプタで作った方が楽そう
  ですね....

  # fj.comp.parallel ではいろんな話になってますね.... conditional
  # critical region は割と便利かも. せっかくオブジェクト指向言語なんだ
  # から, guarded method にする, と.

  ついでに....SizedQueue#num_waiting は残っているのに 
  Queue#num_waiting は残っていないのはなぜ?

  # まあ使い道はあんまり無いんですが. バリアを実装するのにでも使うとか.

======================================================================
  柳川 @ 情報システム学研究科 . 電気通信大学
  [e-mail]                          February 26, 1998
Translaters, traitors.