Polling by sleeping versus polling by waiting with a timeout

Raymond Chen

Commenter Francois Boucher asksit’s better to write a background worker thread that polls withSleep() and a flag, or polls by waiting for an eventwith a timeout?

// method A
while (fKeepGoing) {
 .. a little work ..
 Sleep(50);
}
// method B
do {
 .. a little work ..
} while (WaitForSingleObject(hEvent, 50) == WAIT_TIMEOUT);

“Which scenario is better?The first one uses only 1 handle for the thread.The second one will use 2.But is the first scenario wasting more thread time?Is it worth using the event (kernel object)?”

Yeah, whatever.

I don’t quite understand why you want to pause every so often.Why not just do the work at low priority?When there are more important things to do, your background threadwill stop doing whatever it’s doing.When there is an available CPU, then your background threadwill do its thing as fast as it can (until something with higherpriority arrives).

The only thing I can think of is that by adding the pauses,your program won’t look like it’s consuming 100% CPU while thebackground processing is going on.Which is true, but then again,that’s not much consolation.“Wow, with these changes,my spell check takes only 10% of the CPU.But then again, it also takes 10 times as long.”Is that an improvement?You made your customer wait ten times as long for the document tobe spell checked.That’s ten times less battery life for your laptop.

And generally speaking, polling should be avoided because itcarries negative consequences for system performance.So we’re basically asking, “Which is better, hammering with a screwdriveror hammering with pliers?”

But let’s say for the sake of argument that this “back off periodically”polling loop is actually the right design, and the only argument iswhich of the above two methods is “better” in terms of the criterialisted above (handles, thread time).

It still doesn’t matter.

Method A has one fewer handle, but one more flag.So the total number of things you have to keep track of is the sameeither way.

“Oh, but I save the overhead of an additional handle.”

Dude, you’re already burning a thread.A single handle to an event is noise compared to the cost of a thread.

“But I save the cost of validating the handle and following thereference to the underlying kernel object.”

Dude, you’re about to go to sleep for 50 milliseconds.Saving a few thousand clocks is noise compared to 50 milliseconds.

The flag method does have some other problems, none of which aredeal-breaking, but are things to bear in mind.

First, that flag that you’re checking.There’s no synchronization on that variable, so the background threadmay run a smidge longer than necessary because the change hasn’tyet propagated to the CPU running the loop.Similarly,the sleep loop does take a little longer to notice that it shouldstop working.If the fKeepGoing flag is set to FALSEduring the sleep,the sleep will still run to completion before the loop finds out.

In the grand scheme of things, however, the extra 50 to 100 millisecondsare probably not a big deal.The background thread is a little slow to shut down,that’s all.The user will probably not even notice that the CPU meter was higherthan normal for an additional tenth of a second.After all, the typical human reaction time is 100 milliseconds anyway.

I’m assuming that the code that signals the background thread doesn’tsit around waiting for the background thread to clean up.If it does, then this 100ms delay may start to combine with otherdelays to turn into something the user may start to notice.A tenth of a second here, a tenth of a second there, soon you mayfind yourself accumulating a half second’s delay, and that’s a delaythe human brain can perceive.

Raymond Chen

Follow