JDK-6568526 : (thread) Thread.sleep(millis, nanos) should not return early
  • Type: Bug
  • Component: core-libs
  • Sub-Component: java.lang
  • Affected Version: 6
  • Priority: P3
  • Status: Closed
  • Resolution: Duplicate
  • OS: generic
  • CPU: generic
  • Submitted: 2007-06-12
  • Updated: 2024-04-12
  • Resolved: 2019-03-13
The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.
Other
tbdResolved
Related Reports
Duplicate :  
JDK-8210004 - Thread.sleep(millis, nanos) timeout returns early
Duplicate :  
JDK-6811570 - Thread.sleep returns early
Relates :  
JDK-8065372 - Object.wait(ms, ns) timeout returns early
Relates :  
JDK-5068368 - (thread) Thread.sleep should say "at least as long" and implement this guarantee
Description
Thread.sleep(millis,nanos) might possibly return before
the specified time has elapsed, if nanos < 500,000, because
in that case it rounds down to the nearest millis.

Regardless of whether this behavior is strictly speaking permitted by
the specification, the implementation should "at least" make a "best effort"
to ensure that "at least" the specified time has elapsed.
Comments
EVALUATION Yes. The only time this would cause a difference in the current implementation, where context switches typically happen every 10 millis, is when the context switch happens to come within the (at most half a millisecond interval) between millis and millis+1/2, which will happen at most once in 20 times. It is hard to imagine an implementation depending on this kind of scheduling artifact.
12-06-2007