so setting a timer is equivalent to regularly querying the system time and comparing to a limit
Setting an OS timer would make the thread use 0% CPU. “Regularly querying the system time and comparing to a limit” would not.
Also, a good OS API would allow callers to specify how important it is to be woken at that exact moment, and would use that information to coordinate wake-up times across processes, and thus maximize idle periods.
Setting an OS timer would make the thread use 0% CPU. “Regularly querying the system time and comparing to a limit” would not.
As mentioned, this is the first case and can be achieved by calls to sleep/Sleep/etc. You'd only regularly query if there is actual useful work to be done. That's the premise of the second case you quoted from.
The article is, I reckon, about a rather common case when a thread that does multiplexed I/O also needs to perform some timer-related tasks as well. As the very first paragraph states, "A blocking sleep won't cut it!"
Unless you do it in a separate thread and then signal other threads but that's insane.
Comments
Setting an OS timer would make the thread use 0% CPU. “Regularly querying the system time and comparing to a limit” would not.
Also, a good OS API would allow callers to specify how important it is to be woken at that exact moment, and would use that information to coordinate wake-up times across processes, and thus maximize idle periods.
As mentioned, this is the first case and can be achieved by calls to sleep/Sleep/etc. You'd only regularly query if there is actual useful work to be done. That's the premise of the second case you quoted from.
The article is, I reckon, about a rather common case when a thread that does multiplexed I/O also needs to perform some timer-related tasks as well. As the very first paragraph states, "A blocking sleep won't cut it!"
Unless you do it in a separate thread and then signal other threads but that's insane.