Thread.sleep behaves erratically if system time is changed

Name: dbT83986 Date: 02/10/99


I have a piece of code that sits in a for loop, sleeps for 2
seconds, wakes up and does something (prints "I'm back" in the code
snippet below):

----------------------------------------------------------------------
 

----------------------------------------------------------------------


        Normally, this code runs as expected, i.e. it waits for
2 seconds, and prints I'm back, ad infinitum. However, if I
change the system time while this code is running, it exhibits
the following erratic behavior:

- If the current time is 12:15:00 and I change the time to 11:15:00
  the Thread.sleep (2000) does not wake up for the next one hour + 2
  seconds, which is incorrect.

- If the current time is 12:15:00 and I change the time to 13:15:00,
  the Thread.sleep (2000) works correctly, i.e. wakes up after 2
  seconds.

java.lang.Object wait exhibits an identical erratic behavior.
I tried a similar C program, and this problem was not seen,
i.e. the sleep wakes up after the specified interval regardless
of system time changes. Here's the C program:

----------------------------------------------------------------------
#include <stdio.h>

int main()
{
  int i = 0;

  while(1) {
    sleep(2);
    printf("%d: I'm back\n", i++);
  }
}
----------------------------------------------------------------------
In the presence of this bug, our Java server system hangs when the
system time changes (e.g. during daylight savings time change).

I was wondering if anyone can provide insight into this problem. It
looks like Thread.sleep is behaving as though it cared about the
absolute time, rather than the relative time. If anyone can suggest a
workaround, that would be very helpful to me.


Thanks,



~sumedh
(Review ID: 52515)
======================================================================


1999-12-08: NOTE: a daylight savings time change does
NOT affect gettimeofday(), which uses universal coordinated time (UCT).
Thus, the bug can only arise when system time is abruptly changed.
Changing the system time abruptly is not recommended on enterprise
systems (for instance those running on clusters). Rather adjtime()
should be used to "drift" the time to the right value.
Without further justification as to why the customer wants to abruptly
change time on a running Solaris system, this "bug" will not be fixed.