Original problem description (addressed now: see evaluation):
Users are sometimes reading the javadoc for the two Thread sleep methods
and interpreting it to mean that a program will sleep for *exactly* the
time they are specifying. In reality, all current implementations have an
additional delay before the program resumes execution.  Several bugs have
been filed (and closed) about this.

Current problem description:
The Thread.sleep spec should say that sleep  "Causes the currently executing thread to sleep (temporarily cease execution) for at least the specified number of milliseconds...." (important text is "at least") And the Java SE implementation has rounding policies (e.g. for nanoseconds in sleep's two parameter method) that would not correctly implement this specification change: a code change to implement the "at least" spec properly is also required (see suggested fix).
Posted Date : 2005-08-26 17:06:55.0

N/A

I think we have some wording in java.util.concurrent that might be clearer.

  xxxxx@xxxxx   2004-06-25


We should postpone this till after Tiger because:

- we have some (mild) disagreement about the best wording
  to use.
- Object.wait has exactly the same issues regarding
  whether the timeout has "approximately correct" or "at least"
  semantics, and those should be addressed at the same time.
- We can't really add "at least" until we fix our implementation
  to comply with that.  Currently we might wake up half a millisecond
  early in the sleep(millis, nanos) method.  It's been this way since
  1996.

  xxxxx@xxxxx   2004-07-02

Whenever a thread blocks with a timeout, such as with sleep()
(but also many other methods in the JDK, e.g. in java.util.concurrent)
there is no way to guarantee that the thread will sleep for
exactly the desired time period, because of scheduling issues.
The only thing it is possible to guarantee (assuming a properly
functioning system clock) is that the thread is "dormant" for
*at least* the timeout period.  Currently the JDK does *not*
always comply -- it wakes up early in some situations.
Since we *can* make the guarantee of waiting at least for the
requested time period, we should.  Otherwise, the timeout is nothing
more than a hint.
  xxxxx@xxxxx   2005-04-18 16:58:10 GMT

Following up to the above comment, we can compare the spec for Unix
http://www.opengroup.org/onlinepubs/009695399/utilities/sleep.html
    The sleep utility shall suspend execution for at least the integral number of seconds specified by the time operand.

http://www.opengroup.org/onlinepubs/009695399/functions/usleep.html
The suspension time may be longer than requested due to the scheduling of other activity by the system.

The fact that they use the phrase "at least" lends support to the idea
that we should too.
  xxxxx@xxxxx   2005-07-20 02:52:05 GMT

The clarification aspect of this CR was split off as CR 6312446 to bring the sleep javadoc in line with JLS 17.9 and allow the spec change and implementation change currently proposed by this CR to proceed through the required expert consultation and process, to implement or reject the change.

It has also been observed that the spec and implementation changes to Thread.sleep mentioned above naturally apply to varying degrees to similar methods like Object.wait, Thread.join, methods in java.util.concurrent, etc. If this change is approved generalization will be done with one or more additional change requests.
Posted Date : 2005-08-26 17:06:55.0

Discussion with leading Java concurrency, threading, and realtime experts led to the conclusion that changing the spec with the proposed "at least" wording poses risks to existing users on the one hand and may be impossible to implement with current constraints on Java implementations having to do with retrograde time scenarios on the other. That is, there are limits to detecting the fact that a system's time reference has been moved backwards. This is not to say implementers should not strive to make sleep as precise and accurate as possible.

One specific requirement stemming from this change request is that at the point that the granularity of thread scheduling drops further (becomes finer), implementations may need to revisit delay rounding policies to maintain minimal error rates centered around requested delay values. Making the implementation cognizant (self adjusting) in the face of customization of system parameters is an alternative approach.

Finally, there is a gap between current Java Language Specification (JLS) version 3.0 section 17.9 (covering Thread.sleep) and current method javadoc. This gap will be eliminated in Java SE 6.0 javadoc. The JLS specification of Thread.sleep is here:
 http://java.sun.com/docs/books/jls/third_edition/html/memory.html#17.9
Posted Date : 2005-08-31 15:47:29.0