Hi,
I work on HPUX application and i had a query regarding the sleep & localtime system call in HPUX.
Here is the code that we have :

const uint32_t WAKE_INTERVAL_SEC(30*60);
while (true) {

// Find out what time it is
time(&currentTime);

// Thread to align wakeup with clock 30 minute i.e if it is currently 9:20 wakeup after 10 minutes,
// If it is currently 9:05, wake up after 25 minutes.
// Calculate remaining number of seconds in this half hour.
sleepTime = WAKE_INTERVAL_SEC - (currentTime % WAKE_INTERVAL_SEC);
while (1) {

sleep(sleepTime);

// Do regular work
tptr = localtime(&currentTime);

if (12 == tptr->tm_hour && tptr->tm_min <WAKE_INTERVAL_MIN)
{
// Noon work to be done
}
}

Expected Behaviour:
As refered in above code, we expect that every half an hour, some work to be done and if that time happens to be between 12 and 12:30am then we also do noon work.

Actual Behaviour:
Most of the time it works as expected. But some times, sleep seems to exit a few seconds before 12:30 and so the logic fails and does the noon work. Ideally i would expect that noon work condition to fail, since thread has woke up at 12:30 and hence it cannot satisify noon work condition. ( Trace in syslog indicates that regular work has started at 12:30, but logging itself would have taken some time and i suspect sleep could have woken up early)

Question:
- Can sleep wake up before the schedule time ( other than SIGALRM) ? Are there any other conditions where sleep could wake up before scheduled time?
- Can localtime used for comparison return wrong time ?
- Is it possible that there are some time adjustments done internally(may be for internal clock drifting etc) which results in sleep waking up a second earlier than expected or local time doing some kind of adjustment for some reason?

Any inputs in this regards are appreciated.

Thanks & Regards,
nsv

Why not use cron or at to schedule your code? Those are built to run commands or scripts at exactly the right time.

Plus, sleep(1) is NOT guaranteed to sleep exactly one second.

Hi Jim,
Thanks for the reply.
Actually threads can wake up any time based on the scheduler, so the logic was to check the time the thread needs to sleep so that its aligned with 30 minute intervals.

With Regards,
nsvora

I tried to convey this clearly:

You cannot guarantee EXACTLY how long sleep is. You have to add some slop (fudge factor) in your seconds calculation one way or another, it is not going to work out perfectly every time - example assumes you have POSIX compliant time - ie., no leap seconds.:
time test after wakeup:
You could also try usleep(value ) which has finer granularity in ms, but again value is the MINIMUM. It may be longer. For example a higher priority job than this one is running.