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

From: [e-mail] (Shugo Maeda)
Subject: [ruby-list:6780] Re: Mutex/ConditionVariable/Queue
Date: Thu, 26 Feb 1998 15:28:46 +0900
Message-ID: <[e-mail]>

shugo> |  
shugo> |上のmutexを解除した時点(a)で別のスレッドが動きだしそれが条件を偽に
shugo> する可能 
shugo> |性があります。つまり、signal()によって起されたスレッドに制御を移し
shugo> たいのに 
shugo> |そうならない場合が起きてくるわけです。
shugo> 
shugo> signalの後で他のスレッドが条件を偽にしたら...ということですね。
shugo> # 問題なのはwaitの実装ではなくてsignalした後どのスレッドに制御を
shugo> # 渡すかなのですよね?
shugo> 

そのとうりです。

＃ メールを出したあともしかしたら
＃ 誤解されるかもしれないと思っていました。

shugo> |	Signal-Return   : signalしたプロセスを直ちにreturnさせる。
shugo> 単純。
shugo> 
shugo> すみませんreturnとはどういう意味なんでしょう?
shugo> 

これはmonitor固有の実装になってしまうのですが、signal()とmutexのリリースを
同時にやって呼び出し元がモニタから抜けることを意味します。

意味はそういう意味なのですが実際の処理はwait()の最後のlockをやめてsignal側
ではunlockをやめます。これで無用なコンテキストスイッチが減ります。


shugo> |	Signal-Urgent   : signalを受け取ったスレッドを走らせる。発
shugo> 行元に
shugo> |			  次に走るプライオリティを与える。公平。
shugo> 
shugo> これはRubyのスレッドでは無理のような気がします。

Thread.runだけでは確実ではないのはたしかです。
が、mutexに関係するthreadだけにかぎれば実装することは可能だと思うんですが。


shugo> # runしたスレッドに処理が切り替わるのであれば、現在の動作は
shugo> # これになると思うんですが...。

柳田さんの指摘(たぶんurgentに相当する)にありましたが、signalしたThreadを
queueに管理しないとsignal-urgentになりません。waitしてたやつが
また別のsignalをコールするかもしれないので(Reader/Writerの例もそうなりますね)。

shugo> |	Signal-Continue : シグナルを発行したThreadをそのまま走らせる。
shugo> 
shugo> Rubyだとタイマーでスケジューリングイベントが起こるので、Thread.critical
shugo> をtrueにしないといずれスレッドが切り替わってしまいますよね。
shugo> 切り替わったスレッドがwaitしていたスレッドでなければまた条件を偽にされ
shugo> る可能性があるわけですから同じことではないでしょうか。
shugo> 

そのとおりです。本にもそう書いてあるのですが、本の結論は
	３つとも同様に強力であることは[Howard,1976]で論理的に示されており、
	１つの種類を使用して別のものをシミュレートすることができる。
	実際にどの種類のモニタを選択するかは好みの問題である。
だそうです。

＃ 私も納得していないんですが。

＃ だれか日本語のいいThreadの本知りませんか ?

						S.Senda