ruby-dev

小崎です

素朴な疑問ですが ConditionVariable#wait は何故秒数を返しているのでしょうか？
引数がfloatなら返却値もfloatにするべきだと思いますが。そうすれば誤判定は
だいぶ減るような

2010年5月5日13:22 Yusuke ENDOH <mame@tsg.ne.jp>:
> 遠藤です。
>
> 2010年5月5日12:56 Tanaka Akira <akr@fsij.org>:
>> 2010年5月5日11:46 Yusuke ENDOH <mame@tsg.ne.jp>:
>>>> 秒数で指定すべきでない根拠は何でしょう?
>>>
>>> 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に注意書きぐらいが楽でよいのではないかなぁ

Thread

Prev Next

In This Thread

Prev Next