Re: Thread.sleep and System time change

From: Matt Humphrey (matth_at_ivizNOSPAM.com)
Date: 05/05/04 

Date: Wed, 5 May 2004 10:37:19 -0400

"huy" <nytimes@swiftdsl.com.au> wrote in message
news:4098e189$0$27642$61ce578d@news.syd.swiftdsl.com.au...
>
> That's fair enough. However, it's not so much the accuracy of the sleep
> that I'm concerned about, but the fact that once "it enters the
> execution state"; which I assume is the state it's in once the
> InterruptedException is thrown, it doesn't update my label.

Ok, I think I'm following your problem more closely now. After you change
the system time, the interrupt is meant to restart the clock using the new
time and update the display, thereby avoiding the clock-setback problem. So
currently the time updates about once a second and then you change the time
and the label stops changing. One thing to think about is that if your time
format is is hh:mm:ss the actual seconds will not have changed
noticebly--it's still within the current second.

So really, if you put in print statements that print the current time before
and after the sleep and in the exception, you find that the sleep is
sleeping much too long. (and try interrupting more than once.) At first I
thought that it wouldn't matter if the Date system and Thread system used
different clocks because regardless of whatever time is NOW, the thread
would wake up at NOW + X. However, that's not necessarily true. The thread
may be set to wake up at NOW+X, but the scheduler cannot go backwards in
time. NOW+X has already passed and will not occur again. I can only refer
back to Roedy's page where he says that if someone fiddles with the system
clock, sleep may take a long time or no time. I would have thought that
that warning applied only to sleeps that were already in progress, but maybe
there is some overlap between setting the clock and interrupting the thread
whereby the time is not changed within the scheduler by the time the
interrupt goes off and the re-sleep is using the old time when the new time
comes in.

I don't think I can tell you any more until I've replicated your problem
here.

Good luck,
Matt Humphrey matth@ivizNOSPAM.com http://www.iviz.com/

Relevant Pages

  • Re: Premature wakeup of time.sleep()
    ... >> clock, shich varies from os to os. ... Once you have a wakeup time, you can put your sleeper in a time-ordered queue, ... have the option of a hot return as if the sleep call hadn't happened. ... meaning any time there is any interrupt. ...
    (comp.lang.python)
  • Re: 8ms Timer for serial port access
    ... sleep has a grainularity of 10ms. ... and that's at the next 10ms interrupt. ... -scheduler runs as soon as the driver tasklett completes. ... Disable the FIFO on your UART so you get an interrupt for every byte. ...
    (comp.os.linux.development.apps)
  • Re: newbie delay/sleep question
    ... microseconds and then do some other task. ... another interrupt within that 100 microseconds and the sleep I've been ... Jiffies are increased at every tick (kernel tick, not clock tick), so ...
    (comp.os.linux.development.system)
  • Re: newbie delay/sleep question
    ... microseconds and then do some other task. ... another interrupt within that 100 microseconds and the sleep I've been ... Jiffies are increased at every tick (kernel tick, not clock tick), so ...
    (comp.os.linux.development.system)
  • Re: Conversing with a tcl application...
    ... If the interrupt count for the keyboard, touchpad, ... will awake the computer from the sleep state. ...
    (comp.lang.tcl)