[ruby-dev:43110] Re: pthread_cond を用いたConditionVariable

遠藤です。

2011年1月26日0:32 KOSAKI Motohiro <[e-mail]>:
>>> ええと、いままではGVL持ってるときは他のロックとるの禁止にしてますよね。
>>> GVLスレッドが待ってしまうと、全部止まるから。
>>
>> mutex->lock とかは GVL 持ってる時にロックしてますが、そういう話
>> ではない？
>
> 痛いところつかれた。あれ不思議なんだよなぁ。lock_func()はGVLはずしてから
> 読んでるけど、rb_check_deadlock()はGVLを持ちながらmutex->lockをとるという
> 不思議なつくりが

このへんも試行錯誤の賜物ですね。


>> 私が Ruby を好きな理由は、Kernel#p を始め、デバッグが軽快で楽しく
>> なるようにしているところなので、この程度のことで kill -9 が必要に
>> なるのは嫌です。
>
> それに対する答えは１つしかなくて、CVなんか使うな。ですよ。
> そういう中断できないAPIを選んでるんだから。
> 気持ちよくCtrl+Cで中断したい人はpipe でスレッド間通信しておけばよかったわけです。

どうせ Ruby は今 CV 以外にも全面的に Ctrl+C に脆弱な状況なのに、なんで
CV だけ利便性 (1.9.x も変えようというなら互換性も) を捨てて Ctrl+C 対策
しないといかんのかが、どうも腑に落ちない感じです。


> どうしてもCVが使いたければ、プログラムの最初でスレッドつくってmainスレッドはthread.joinするだけ
> にしとけば、絶対割り込み可能です。これは十分現実的でしょう。

プロセス終了時に全スレッドに例外 (のようなもの) を投げて join するはず
なので、おそらく無意味です。


>> こんな感じですかねえ。
>>
>>  class SynchronizedQueue
>>    def initialize
>>      @array = []
>>      @cv = ConditionVariable.new { !@array.empty? }
>>    end
>>    def push(x)
>>      @cv.signal_and_synchronize { @array << x }
>>    end
>>    def pop
>>      @cv.wait_and_synchronize { @array.unshift }
>>    end
>>  end
>
> cv.wait 以外はspurious wakeup問題がないので、特に拡張は不要という
> 認識でした。これは構文の一貫性のためだと思って良いのでしょうか？
> 見逃しがあったら教えてください。

必須ではないですが、こういう API にしたほうが「cv と mutex をペアとして
扱うこと」や「cv と predicate をペアとして扱うこと」を強制できるので、
そのあたりの誤用も減らせるのではないかと。

ただ、それによって表現力が落ちている可能性はあるのと、もはや Condition
Variable ではないなどのツッコミはありえます。


>> そもそも、注意点を網羅的かつ明確に理解できている人が現時点で存在
>> しないという説。
>
> 遠藤さん理解してはるじゃないですか・・・・・

他人の間違いは探せても、体系的に説明できるほど整理できないんですよねえ。

-- 
Yusuke Endoh <[e-mail]>