while (true) {
    sleep(seconds(1));
    log(get_current_time());
}

This question isn't specific to any one language.

Is it possible to guarantee that this thread records log entries exactly one second apart? From what I understand, after 1 second of sleep, the thread will be woken up and marked as runnable in the kernel but depending on which other threads are runnable and their relative priorities (or perhaps other busy work that must be done), the kernel may not schedule the thread to run until a small amount of time after. This may cause the log entries to be 1.1 seconds apart.

Can anything be done in user-level code to reduce this variance? Besides just having as few other threads as possible.

CodePudding user response：

You can't. There is no guarantee that the thread will run in every second. When there is a call to sleep or threading implementation uses internal scheduler (like in Java) and you are not controlling this scheduling, you are relying on luck. This is why you need external tools like quartz and other task schedulers. What is the purpose of logging time intervals when they are not reliable? Logging should be reliable. If it is not, what is it worth?

CodePudding user response：

You will never get the timing that you want, without resorting to non-portable implementation specifics. Just sleep(1)ing the thread is the right thing to do. On some (read: most) platforms, a thread that runs at this level cannot run at all if there is not some CPU work to do. This means that other non-sleeping threads will get scheduled onto the CPU ahead of the sleep-ing one. Now, depending on the OS kernel and on how the scheduler works, it might very well be that it never schedules the sleep-ing thread to run again. If it runs again, then the OS scheduler makes sure that all the threads, including the sleep-ing thread, get their turns to run. This isn't guaranteed, however. I have seen systems where the sleep-ing thread was constantly getting scheduled again and again (by different OS threads, so it didn't get scheduled when expected), which would cause it to run multiple times per second and waste CPU cycles. In general, you have a large degree of freedom to decide how to handle multi-threaded code, and if you want to get reliable timing (with negligible CPU use) then you will need to get the OS scheduler involved. If the thread is blocked on a sleep(1) or other form of blocking, then you can make sure that the thread won't run at the same time as anything else, but you cannot get it to run at any given rate (it will always be subject to change). On the other hand, if you use an implementation where a sleep(1) is interpreted as an opportunity to be removed from the run queue, then you might be able to write an event loop that runs at the rate that you want.