From: KOSAKI Motohiro Date: 2010-05-06T23:15:45+09:00 Subject: [ruby-dev:41207] Re: MonitorMixin::ConditionVariable#wait timeout 2010年5月6日23:08 Yusuke ENDOH : > 遠藤です。 > > 2010年5月6日20:13 Tanaka Akira : >> 2010年5月6日19:58 Yusuke ENDOH : >> >>> Mutex.sleep は pthread_cond_timedwait で実装されているため、API 上で >>> relative time を受け取ってもシステムクロック変更対策は実現できないの >>> ではないでしょうか。 >> >> そうですね。 >> relative time で受け付ける機能数がある環境でしか完全には実現できない >> かもしれません。 >> (MacOS X の pthread_cond_timedwait_relative_np とか?) >> >> そういう環境では正しく動き、そうでない環境では残念ですが >> 時刻を巻き戻した場合は遅くタイムアウトすることになるでしょう。 >> >> しかし、absolute time しか指定できなければ、 >> 遅くタイムアウトしないという機能を提供することは不可能です。 > > > 考えてみたら、relative time を指定しても、spurious wakeup した場合に、 > システムクロックが信頼できないとなると、あとどれだけ wait すべきなのか > 計算できない気がしました。 今のtimeクラスはmonotonic時間はとれないんでしたっけ？ > 「あとどれだけ wait すべき」という情報もあわせて教えてくれる機能が > ある環境って存在するんですかね。 Linuxのselectぐらいかなぁ。まあ一般的ではないのでrel-time使う時は spurious wakeupがないと信じる。という事になりそうですねぇ 現実問題としては、ほとんどの環境でシグナル以外でspurious wakeupが ない実装になっていると思うし、シグナルはタイマースレッドに いくはずなのでrubyではあんまり問題にならない気もします。 でも全然確信が持てませんが。