The current implementation of Thread.sleep(ms) on Windows has inconsistent behavior, based on whatever the minimum timer resolution is on a particular runtime platform.
I have attached 2 apps, one Java and one native win32 (you'll need to link with winmm.lib to make the native app compile). The apps have the same behavior on my system (XP laptop, P4 3.4GHz) _except_ for sleep times in increments of 10 ms. For these values, the Java app sleeps for about 16 ms, whereas the native app sleeps for the expected time.
What you end up with is inconsistent behavior for sleep(), where an app will sleep for about the right amount of time for any value passed in except values that are multiples of 10 ms. For example, sleep(9) will sleep fro about 9 ms,
sleep(11) will sleep for about 11 ms, but sleep(10) will sleep for 16 ms (on my system).
I have attached 2 apps, one Java and one native win32 (you'll need to link with winmm.lib to make the native app compile). The apps have the same behavior on my system (XP laptop, P4 3.4GHz) _except_ for sleep times in increments of 10 ms. For these values, the Java app sleeps for about 16 ms, whereas the native app sleeps for the expected time.
What you end up with is inconsistent behavior for sleep(), where an app will sleep for about the right amount of time for any value passed in except values that are multiples of 10 ms. For example, sleep(9) will sleep fro about 9 ms,
sleep(11) will sleep for about 11 ms, but sleep(10) will sleep for 16 ms (on my system).
- duplicates
-
JDK-5005837 rework win32 timebeginperiod usage
- Closed