timeBeginPeriod lets a program request a smaller timer interrupt interval by passing in a requested timer interrupt interval. Some programs (WPF, SQL Server, Quartz, PowerDirector, Chrome, the Go Runtime, many games, etc.) find this much variance in wait delays hard to deal with but luckily there is a function that lets them control this.
WINDOWS XP TIMER UTILITY WINDOWS
In short, it is the nature of timer delays that (unless a busy wait is used, and please don’t busy wait) the OS can only wake up threads at a specific time by using timer interrupts, and a regular timer interrupt is what Windows uses. That means that if you call Sleep(1) at some random time then you will probably be woken sometime between 1.0 ms and 16.625 ms in the future, whenever the next interrupt fires (or the one after that if the next interrupt is too soon). The interval between timer interrupts depends on the Windows version and on your hardware but on every machine I have used recently the default interval has been 15.625 ms (1,000 ms divided by 64). This means that the thread may end up waking up a bit late, but Windows is not a real-time OS and it actually cannot guarantee a specific wakeup time (there may not be a CPU core available at that time anyway) so waking up a bit late should be fine. When a thread calls Sleep(n) then the OS will schedule the thread to run when the first timer interrupt fires after the time has elapsed. There are lots of ways to coalesce wakeups but the main mechanism used by Windows is to have a global timer interrupt that ticks at a steady rate.
If multiple threads can synchronize or coalesce their timer waits then the system becomes more power efficient. CPU power efficiency is strongly tied to how long the CPU can stay asleep ( 8+ ms is apparently a good number), and random wakeups work against that. If there are many threads all waiting on timers then the OS could program the timer chip with individual wakeup times for each thread, but this tends to result in threads waking up at random times and the CPU never getting to have a long nap. The WaitForSingleObject and WaitForMultipleObjects functions also have timeout values and those timeouts are implemented using the same mechanism. The OS programs a timer chip that then triggers an interrupt that wakes up the CPU and the OS can then schedule your thread. Ideally the CPU goes to sleep when Sleep(1) is called, in order to save power, so how does the operating system (OS) wake your thread if the CPU is sleeping? The answer is hardware interrupts. It’s worth pausing for a moment to think about how this is implemented. And so we have the Windows Sleep function – pass it the desired length of your nap in milliseconds and it wakes you up later, like this: This actually shouldn’t be done very often – threads should normally be waiting on events rather than timers – but it is sometimes necessary. It is desirable for a program to be able to go to sleep and then wake up a little while later. Timer interrupts and their raison d’êtreįirst, a bit of operating-system design context.
WINDOWS XP TIMER UTILITY UPDATE
If any of my conclusions are wrong then please let me know and I will update this. Update, 2021: this change is acknowledged now in the timeBeginPeriod documentation. Fair warning – all I have are the results of experiments I have run, so I can only speculate about the quirks and goals of this change. I think the new behavior is an improvement, but it’s weird, and it deserves to be documented. There is still an effect, and thread delays from Sleep and other functions may be less consistent than they used to be (see section below), but in general processes are no longer affected by other processes calling timeBeginPeriod. The short version is that calls to timeBeginPeriod from one process now affect other processes less than they used to. So far I have found three programs that hit problems because of this silent change. This isn’t the first time this has happened, but this change seems bigger than last time. The behavior of the Windows scheduler changed significantly in Wind(aka, the April 2020 version of Windows), in a way that will break a few applications, and there appears to have been no announcement, and the documentation has not been updated.
0 kommentar(er)
