From: SASADA Koichi <ko1@...>
Date: 2012-11-28T12:22:45+09:00
Subject: [ruby-dev:46645] Re: [ruby-changes:25810] kosaki:r37867 (trunk): * thread.c (rb_mutex_trylock, rb_mutex_unlock, mutex_sleep):

どもども．

(2012/11/28 11:29), KOSAKI Motohiro wrote:
>> Mutex#lock とかを，trap handler 中で出来ない，ってのは，すみません，どの
>> 辺の話でしたっけ．
> 
> [ruby-dev:46434] とかで議論したときに、当分
> trapからmutexが使えない制限は直さないということだったので、メージ的に例外投げるようにしました

　「2.0 では trap で main がロックしているときにもう一度 lock を取ろうと
するとデッドロックするのは直さない」ですよね．

　なので，今回の提案は「main がロックしているとき」という条件を付けよう
という話となっています．

>> ruby-spec がこれで落ちているので気がつきました．
>> すみません，これってそういうものでしたっけ．
>> ちょっと，大きすぎるように思いまして．
> 
> 関係あるかどうかわかりませんが、ささださんがircでtry_lockで落ちたと発言したログが残っていたので try_lockだけ例外出さないように変えました。
> try_lockはdeadlockしないので。

　そうですね．

>> main thread と trap handler 中で競合が発生する（デッドロックになる）のは
>> わかるんですが．
>>
>> ちょっとした回避策ですが，
>>
>> (1) main thread がロックを保持している
>>     時のみ，Mutex#lock が例外を発生させる
>>
>> というのはどうでしょうか．これによって，
>>
>> (a) trap 内で完結する lock はちゃんと動く
>>   （trap 内で unlock しない奴は死ねばいい）
>>
>> (b) sub-thread で lock している奴は，trap 内で待つことができる
>>
>> と出来ると思います．いかがでしょうか．
> 
> ２つの理由から好きではありません。1) mutexがlock ownerを保持しているのが議論の前提になっているが、deadlock
> detectionがない実装ではないではたぶん保持していないであろう

　他の実装は，例えば trap 中で main と競合しない可能性があるので，考えな
くても良いと思います．CRuby 2.0.0 の制限という位置づけですから．

> ２）それではダメなプログラムを書いた時に、テストで通って本番で落ちるという最悪の結果になってしまい、deadlockからたいして好転していない
>
> 私の考えだと例外はプログラムが間違っていると教えて上げるためにあげているので、テストした時にうっかり通ってしまうような条件はあまり好きではなく、一般的にはレースしてそうなら例外という条件もあまり好きではありません。

　まずい使い方をすると時々通り，時々困るので全部失敗とさせてしまおう，と
いう考え方は理解出来ます．　

「Mutex だとタイミングの問題でたまたま main と trap でテストの段階で競合
が発生しないことがあるので，この変更で全部禁止にしてしまおう」ということ
で，テスト時には再現しないが，出荷後に見つかるバグが埋め込まれる可能性が
ある，ということですね．これを排除する方向は良いと思います．


　ただ，main と trap が競合しない，ということを利用者が注意している状況
でも，一切利用できない，という変更なので，躊躇しています．多分，既存のス
クリプトに結構ありそうじゃないかと．

　警告を出す，とすると中途半端で誰も救えないかなぁ．うーん．大きな変更な
ので，まずは警告を出すようにする，という方針は，それはそれでありな気もし
ますが．

　ちょっとまとまりませんが，とりあえず送っておきます．


>> ちなみに，POSIX thread はどうなってるんでしたっけ．
> 
> trylockも含め、すべてsignalハンドラで使うと動作する保証はありません

　なるほど，そうでした．

-- 
// SASADA Koichi at atdot dot net