S_a_k_Uの日記みたいなDB

~サクゥーと呼ばないで~

Calling Thread.sleep with small argument affects system clock on windows.

Sun Java 1.6.0_03(多分1.5.0_11も同じ)
while文でThread.sleep(1)って感じで、結構な回数ループさせると、





システムクロックが進んじゃってるんですが(汗
(1分で5秒くらい)



んで調べてみると、続々・システムクロックが進む問題で言及してて、
Bug ID:4500388 Calling Thread.sleep with small argument affects system clock on windows
ということらしい。
ん?でもBugFixしてるぞ?
と思ったけど、下の方でまだ直ってねぇぞって?
ForceTimeHighResolutionってJavaVMのオプションで解決するんかと思ったけど、Windowsの時計が勝手に進んでしまいます。とのこと。



Bug ID:6435126 ForceTimeHighResolution switch doesn't operate as ntended
Bug ID:6464007 System clock acceleration still exists on Windows XP
VM側としては、原因はwin32のtimeBeginPeriod/timeEndPeriodというAPIにある感じ。
そのAPIで最小タイマ分解能の設定と復元って処理をしてる時に、システムクロック速めちゃうってことかな???
設定された最小タイマ分解能の時間より、
・復元&再度設定に処理が掛かってしまうような場合?
・それより速く復元&再度設定に来た場合?
ってな場合に、APIの中で補正とかしてそうな予感?
だから、VM側でThread.sleepは10[ms]以上でないとダメよみたい感じにしてるのかな???


hal.dllってヤツがそのモジュールか?正式ファイル名はhalmacpi.dllになってるけど、マイクロソフトのフィードバックの情報?のKB:821893ってのが見たいんだけど見えん。
それで検索してみたら、またsatoshiさんの記事(続々々々・システムクロックが進む問題)が、って問題はCPUって???
OSがそのCPUのAPI使ってるのがダメなんか、CPUの実装が異なるってことがダメなんかよう判らんけど、
Windowsでは10[ms]以下の間隔での処理はできん
ということか。
んで、感覚的にHAL(Hardware Abstraction Layer)ってハードウェアを抽象化するインターフェースのレイヤで、halaacpi.dllとかhalmacpi.dllってのがその実装って感じなんかな???
しかし、CPUって話になるとUNIX系のVMでも同じじゃねんかな???
OSのAPIが違って、VMの実装が違うってことか?


オムロンさんもFinsGatewayというミドルウェアで同じ問題が発生してるらしい。
んでも、回避策の

timeGetDevCaps関数により得られるタイマ分解能の最小値よりも大きな値をtimeBeginePeriod関数およびtimeSetEvent関数に設定することで、この現象が発生しないことを確認しました。

ってことは、timeGetDevCaps関数の値が拾えれば、sleepの精度が判るんかな???