timeBeginPeriod and timeEndPeriod can cause (a) time-of-day clock skew, and (b) degraded perforamnce because of the increased interrupt rate. For sleep requests that are "long" (perhaps > 1sec) or are a multiple of 10 msecs we should consider avoiding timeBeginPeriod-timeEndPeriod.
Remarks:
* See the java-3d timer/timertest demo
* See http://www.sysinternals.com/ntw2k/info/timer.shtml for a description of how timeBeginPeriod and timeEndPeriod are implemented.
Thoughts:
* Defer loading winmm.dll
* We should measure the cost of the calls to timePeriodBegin and timePeriodEnd. If either operation is expensive we could (a) use a process-specific globals "timerUsers" and "currentResolution" to avoid redundant timePeriodBegin and timePeriodEnd calls. We would define a timeperiodbegin call as redundant if the current resolution is already >= the requested resolution. (b) call timePeriodBegin only to increase the resolution. Periodically, perhaps in the watcher thread, if high res timers haven't been required in the last N secs, restore (decrease) the resolution with timePeriodEnd. That is, we'd defer calling timePeriodEnd. The intent is to eliminate chains of calls to timeperiodbegin and timeperiodend that simply increase and then decrease the timer resolution.
* Before calling timeperiodbegin() we should verify that the system supports the requested resolution via:
TIMECAPS tc;
if (timeGetDevCaps(&tc, sizeof(TIMECAPS)) != TIMERR_NOERROR) {
// Error; application can't continue.
}
const UINT wTimerRes =
min(max(tc.wPeriodMin, TARGET_RESOLUTION), tc.wPeriodMax);
timeBeginPeriod(wTimerRes);
###@###.### 2004-03-01
###@###.### 10/8/04 14:08 GMT
- duplicates
-
JDK-5091934 Thread.sleep() on Windows has inconsistent behavior
- Closed
-
JDK-4717583 High resolution Thread.sleep() needs lower overhead on Windohs
- Closed
- relates to
-
JDK-6313903 Thread.sleep(3) might wake up immediately on windows
- Resolved
-
JDK-4653558 Java Application startup time is SLOW in JDK 1.4 compared to JDK 1.3.1_02
- Closed
-
JDK-6435126 ForceTimeHighResolution switch doesn't operate as intended
- Closed
-
JDK-4500388 Calling Thread.sleep with small argument affects system clock on windows
- Closed
-
JDK-4712392 REGRESSION: Reduced default resolution for Thread.sleep() breaks apps.
- Closed