From: KOSAKI Motohiro Date: 2010-05-05T16:48:57+09:00 Subject: [ruby-dev:41162] Re: MonitorMixin::ConditionVariable#wait timeout 小崎です 素朴な疑問ですが ConditionVariable#wait は何故秒数を返しているのでしょうか？ 引数がfloatなら返却値もfloatにするべきだと思いますが。そうすれば誤判定は だいぶ減るような 2010年5月5日13:22 Yusuke ENDOH : > 遠藤です。 > > 2010年5月5日12:56 Tanaka Akira : >> 2010年5月5日11:46 Yusuke ENDOH : >>>> 秒数で指定すべきでない根拠は何でしょう? >>> >>> http://www.opengroup.org/onlinepubs/009695399/functions/pthread_cond_wait.html >>> >>> で、pthread の RATIONALE として説明されています。 >> >> Timed Wait Semantics の項ですか? > > そこと Timed Condition Wait のところです。 > ただし正直、その文章を正しく理解できている自信はあまりありません。 あの文章が言っていることももっともなんだけど、じゃあ時刻変更とraceが起きたら どうするんだろうとか違う問題がある気がするんですよねぇ。 私が分かってないだけかもしれませんが。 # Timed Wait Semantics の項には時刻スキップが起きた場合の動作について # 説明はありますが、時刻巻き戻し時は枕を濡らせと言っているように感じる >> 本当に禁止すべきものなら >> たまたま 1.9.1 で動かなかったので、これ幸いと禁止してしまう、というのも >> ありうる選択肢かもしれませんが。 >> >> 問題は本当に禁止すべきものなのか、という点ですね。 > > 使ったら race condition の発生を促進してしまうような API だとしたら、 > 提供すべきでないと思います。 > 少なくとも、rdoc で注意と正しい使い方を示すべきだと思います。 > > 絶対時刻が指定できない限り、「正しい使い方」が存在しないと思います。 > なので、絶対時刻指定が実装されない限り、1.9.2 で中途半端なものと提供 > すべきでないと思います。 > 絶対時刻指定も new feature なので、今から 1.9.2 に盛り込むべきでない > と思いますが、実装する人がいるなら断固反対というほどではありません。 いやぁ、相対時刻はうれしいですよ。典型的ユースケースにLaiさんがあげている N秒に一回起床してきて定期処理を実行するというのがありますが、 要求が「N秒に１回」なので相対時刻のほうが素直だし秒単位の話をしてるなら preemptの誤差なんてたかが知れているし・・ Timed Condition Wait のほうの話は絶対時刻を引数にとるという案とLinuxのselect(2)の ように経過時刻を返すという案の2案があるのだけど、相対時刻APIは絶対時刻APIの ラッパとして実装できるでしょ。というのがpthreadの理屈だと思っていて あんまり使い勝手への配慮がないなぁと感じています。 > また [Bug #2629] では、timeout でリターンしたかどうかを返り値として > 伝えるべきだ、という指摘もあります。これが、 > > - ないとまずい > - なくてもよい > - あるとまずい > > のどれかという判断もいまいちしかねています。こっちはどう思いますか？ +1 => ないとまずい 一般論としていうと、原因不明でも実装できるのはリトライが安全なケースに限られると思っていて Cond#waitの場合、Cond#signalされたあともう一回waitすると寝てしまうので 「できるかぼけ」と壁を叩くケースが出るんじゃないかな 僕の中では、相対時刻を取っていることよりも ・経過時刻が秒数に丸められており、かつ ・ETIMEDOUTかどうかを知る手段がない が問題に見えます。 > # 完全に余談ですが、Mutex#locked? もロジック中で使うべきでない要注意 > # メソッドだと思っています。 > # - http://d.hatena.ne.jp/ku-ma-me/20080111/p1 > # - http://d.hatena.ne.jp/ku-ma-me/20080114/p3 脱線ついでにLinux kernelの話をすると、hogehoge_is_locked() はほとんどBUG_ON （Linuxの中でのassert相当）で使われています。 （一部Adaptive mutex等の実装に使っている変態さんがいるけど） で、テストとかを考えると関数先頭に「XYロックがとれてなかったらpanic」という 処理は要望があるように思います（Rubyだと例外になるのかな?） 私の理解では、あっちの世界で所有者チェックをしていないのは、 単にほぼデバッグ用の機能に複雑な実装入れ込みたくないから だと理解しています。 なので、RubyのMutex#is_locked? も同じで、initial implement時に ownerを実装するのが面倒だっただけだと推測しています。 Mutex#own? の実装については「反対する理由はないけど事前ではきっとやらない」 ぐらいの価値観ですかねぇ。unless is_locked? のfalse positiveは大変レアなので テスト程度なら困りませんし。rdocに注意書きぐらいが楽でよいのではないかなぁ