JDK-4240408 : java.lang.Thread.sleep(millis, nanos) sleeps less than specified.
  • Type: Bug
  • Component: core-libs
  • Sub-Component: java.lang
  • Affected Version: 1.2.2
  • Priority: P1
  • Status: Closed
  • Resolution: Not an Issue
  • OS: windows_95
  • CPU: x86
  • Submitted: 1999-05-21
  • Updated: 1999-06-02
  • Resolved: 1999-06-02
Related Reports
Relates :  
JDK-4373068 - Thread.sleep() does not work as expected in Solaris.
Relates :  
JDK-4143354 - java.lang.Thread.sleep(millis) sleeps less than specified.
Relates :  
JDK-4123961 - (hpi) Need higher resolution System.currentTimeMillis on Win32
Description
jdk1.2.2T on Windows95 fails JCK1.2 test

api/java_lang/Thread/sleep02/sleep0201/sleep0201.html 

(sleep0201.java 1.4 98/08/31 with bug 4166410 fixed).

with following test output:

test result: Failed. sleep(100,3162) actually sleeped only 100000000 nsec

The test already assumes that clock accuracy on windows95 is 50 ms and 
adds 50 ms to the period of time before and after the call to sleep(,).

So the diagnostics means that sleep(100,3162) actually sleeped some
time which is strictly less than 100000000 nsec while it should sleep at least
100003162 ns.
Comments
EVALUATION The test appears to assume that the sleep time will always be strictly greater than the time requested, implying that the time will be effectively rounded up to the next larger multiple of the clock granularity. In fact, the code chooses to round to the *nearest* millisecond (with a 1msec minimum for a non-zero request) before forwarding the request to the OS. Thus the request for 100003162nsec is treated as a request for 100000000nsec. Since the spec doesn't say what happens when the requested sleep time cannot be provided precisely, this behavior appears to be justifiable, and indeed quite reasonable. william.maddox@Eng 1999-05-24 I agree with Bill's evaluation. The spec makes no guarantees concerning the relationship between System.currentTimeMillis and Thread.sleep. The spec does not indicate how either of these calls should behave if the JRE is not capable of the implied precision (milliseconds or nanoseconds). Finally, the "fudge factor" of 50 ms. contained in the test is not mentioned anywhere in the spec (so far as I know). In summary, I believe the test is invalid, and should be excluded. joshua.bloch@Eng 1999-06-02
02-06-1999