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

From: [e-mail] (Shugo Maeda)
Subject: [ruby-list:6770] Re: Mutex/ConditionVariable/Queue
Date: Wed, 25 Feb 1998 20:31:43 +0900
Message-ID: <[e-mail]>

shugo> 前田です。
shugo> 
shugo> In message "[ruby-list:6767] Re: Mutex/ConditionVariable/Queue"
shugo> Yukihiro Matsumoto <[e-mail]> wrote:
shugo> 
shugo> ||Rubyのスレッドは全部同じ優先度で均等に実行される(ですよね?)ので
shugo> ||多分問題ないと思うのですが、実際のところどうなんでしょう。
shugo> |
shugo> |現状のrubyのスレッドに優先度が無いのは本当です．問題が無いか
shugo> |どうかは私には分かんないんです．すいません．
shugo> 
shugo> JavaだとUNIX版ではタイマーによるスケジューリングイベントがな
shugo> いので一つのスレッドが走り続けたりしますけど、Rubyではそうい
shugo> うことがないので特にスケジューリングを気にしなくても問題は起
shugo> きないんじゃないかなと思っていました。
shugo> # というのは楽観的すぎるのでしょうか＞Sendaさん

ええと、Threadのユーザであっても実装者ではないので内部の都合で必要かどうか
は良くわからないのですが、

ただ、ユーザの立場で優先度を変えたい場合というのは、アプリケーションと計算
機の資源の関係で決まると思います。資源に余裕のあるときは別に優先度を変えた
いなんて思いません。だけれど、やりたいことに対して資源がギリギリであるよう
な場合チューニングが必要になってきます。

たとえば、rubyでTkでGUIを作って裏で何らかの計算やファイル入出力をやってい
るとするとき、裏の仕事が軽い場合は何にも問題はないのですが、おもい場合、
GUIのレスポンスが悪くなっては困るので表の方の優先度をあげたいとかいうこと
はよくある話です。

>＃ threadの実装は良く知らないのですが、signal()のあとどこのthreadに制御を
>＃ 移すかがキモらしい。

このたわごとの出典は
	T.Q.パム、P.K.ガーク 著  川手恭輔 訳
	WindowsNT マルチスレッドプログラミング入門 (トッパン)
のモニタのシミュレートの章なのですが、
読み直してみるとスレッドの実装の問題ではなく条件変数の処理に関わるものでし
た。この章であまり良くない実装例として上がっているものと前田さんの実装が一
致しています。:-(

  def wait(mutex)
    mutex.unlock   # <------------------ (a)
    @waiters_mutex.synchronize {
      @waiters.push(Thread.current)
    }
    Thread.stop
    mutex.lock     # <------------------ (b)
  end
  
上のmutexを解除した時点(a)で別のスレッドが動きだしそれが条件を偽にする可能
性があります。つまり、signal()によって起されたスレッドに制御を移したいのに
そうならない場合が起きてくるわけです。

＃ べつにそうなったからといって全体の動作が狂うわけではない。

この本ではそうならない実装として
	Signal-Return   : signalしたプロセスを直ちにreturnさせる。単純。
	Signal-Urgent   : signalを受け取ったスレッドを走らせる。発行元に
			  次に走るプライオリティを与える。公平。
	Signal-Continue : シグナルを発行したThreadをそのまま走らせる。

の３つのやり方が紹介されています。詳しくはこの本か別の文献を当たってみてく
ださい。

＃ Rubyで書いて示したいところだけれど今時間が。。
＃ 土日にかいてみてもよいけれど。

							S.Senda