ささだです。

Shiro Kawai wrote:
>>　で、その監視のタイミングなのですが、rb_eval() （今の Ruby 評価機）では
>>node ごとにチェックしているが、チェックの間隔が短すぎるとオーバヘッドが
>>大きくなるし、長すぎる（もしくはチェックしないタイミングが任意に引き伸ば
>>せる）とスレッドスケジューリングが
> 
> 
> オーバヘッドは
>  (1) 現在のVMが時間を使いきったかどうかのフラグチェック
>  (2) 待ちスレッドが無い状態でmutex_unlock/lockを行うこと
> 
> の2つがあると思うのですが、(1)に関してはよっぽどVMの性能が良くない
> 限り問題にならないのではないかと思います。GaucheでもVM instruction
> 毎にシグナルとファイナライザのためにフラグをチェックしていますが
> これを省いて性能測定してみても差はほとんど出ませんでした。
> なので、フラグチェックに関しては細粒度でやっていいんじゃないかと
> 思います。
> 
> (2)の方は多分深刻で、シングルスレッドアプリであるにもかかわらず
> タイムスライス毎にmutex_unlock/lockを呼ぶのは相当なオーバヘッドに
> なると思いますが、「待ちスレッドがあるかないか」だけをmutexの操作
> 無しでチェックできれば回避できるんじゃないでしょうか。

　なるほど。(1) を問題だと考えていたのですが、そうでもないのですね（これ
は実測して確認します）。

　たまにしか起こらないので (2) は大したこと無いと思ってました。そうでは
ないのですね。現在待ち状態のスレッドの数を管理する変数（その変数のインク
リメント、デクリメントは排他制御しなきゃいけないか）が一つあれば、それで
問題は解決しますかね。

　POSIX でアトミックに変数の値を変更するプリミティブって提供されてないで
すよねぇ。とりあえず、pthread_mutex_lock を使うしかないか。

-- 
// SASADA Koichi at atdot dot net
//

--
ML: yarv-dev quickml.atdot.net
使い方: http://www.atdot.net/~ko1/quickml