Go to Sleep


hutch-- wrote:
>
> Show us how you provide an alternative to a polling loop that checks an
> exit code, polls a keystroke and displays duration on te console title
^^^^^^^^^^^^^^^^^

Well, clearly you can't provide an alterative to polling that does
polling. Then it wouldn't be an alternative to polling, would it :-)

> bar while running at ZERO percent processor usage. How many percentage
> points improvement can you get with the technique you have insisted is
> technically superior ?

I have no idea what the argument is about, nor do I really care. But as
long as the OS can provide an event that you can wait on, waiting for
the object is generally better than polling until the object is
available. And this really has little to do with efficiency and
*everything* to do with proper synchronization. You can wait for a
process to complete (so you can check its error code return value), you
can wait for a keystroke to occur. I'm not sure what polling has to do
with displaying a duration in console title bar, so I can't comment on
that. Bottom line, though, is that sleeping and periodically waking up
(to poll for some event) is the right thing to do *only* when there is
no way for the hardware (e.g., keyboard) or system (e.g., a process
terminating) to notify your process that an event has occurred.
Whether or not sleep is significantly slower, this just *isn't* the
right thing to do. The right thing to do is to wait on the specific
events (process termination, to get the return code, or a keypress
event). Even if these operations were *less* efficient (and they are
not), blocking on those events is the right way to handle them. Sleep
is a hack, pure and simple.

Let me share a story with you. I'm currently rewriting a control
program for a small research reactor. The software is written in C
under QNX 4.0. The guy who originally ported the code from ICDOS to QNX
4.0 was fond of sticking in "delay(n);" calls all over the place (like
sleep, but in milliseconds). There are probably a dozen different
processes running on two computers (one in the control room, one down
by the reactor). All synchronization is done by these delay calls. As a
result, when faster computers come out, the synchronization between the
two systems and all the processes fails -- it's not unlike the games of
yesteryear that used a delay loop for timing (which broke
spectactularly when faster CPUs arrived). Debugging this code is a PITA
because failures aren't consistent. All of these could have been
avoided if proper synchronization primitives had been used.

Maybe your little sample program (whatever it is) works just fine with
a sleep loop. But by using sleep, and not learning how to do it
properly, chances are pretty good that you'll use sleep again, the next
time you need a synchronization primitive. And the time after that. And
the time after that. And before you know it, you've got a very unstable
system controlling a nuclear reactor. Better to figure out how to do it
right from day one and practice that methodology in all code you write.
That way, you don't wind up with fragile code because you've gotten in
the habit of using a hack to synchronize things.

Again, I want to point out that I've not got a clue what your program
does. But unless it's measuring time intervals or waiting on some
time-based event, sleep is not the proper primitive to use here.
Cheers,
Randy Hyde

.

Relevant Pages

  • Re: Re-entrancy???
    ... Using Doevents in a polling loop, which is what you have been trying to force down everyone's throat in your customary nasty manner, will cause the processor to run at 100 % and will cause the polling to occur at a rate of anything up to about a million polls per second on a typical machine, depending on the exact nature of whatever it is you are polling and how long it takes to read it, which is totally unnecessary in almost all cases, and specifically in the OP's case. ... If you really do need to poll stuff then there are other ways of performing polling, using either a standard Timer or a Hires Timer to do the actual repeated polling for example and then throwing an event when the result comes in, which will use very little processor time without requiring you to put your thread to sleep and which is suitable for lots of cases, but if you are going to use a Do Loop as a polling loop with DoEvents inside the loop at every iteration as you have suggested yourself and if a polling rate of up to 500 polls per second is sufficient, which it very definitely is in the OP's case and in many other polling cases, then it is wise to add a Sleep 1 to the loop, using the appropriate timeBeginPeriod if polling is required at ...
    (microsoft.public.vb.general.discussion)
  • Re: MSCOMM a Processor Hog?
    ... If you are polling using a loop or loops (with DoEvents), ... You can add a call to Sleep after the DoEvents, ...
    (microsoft.public.vb.general.discussion)
  • Re: MSCOMM a Processor Hog?
    ... If you are polling using a loop or loops, ... including a call to Sleep, then yes, this is normal. ... DoEvents does call Sleep. ...
    (microsoft.public.vb.general.discussion)
  • Re: event vs volatile bool
    ... If you need polling do that with sleep without event ... >> In your case it's the same but in really you don't need while loop in ...
    (microsoft.public.win32.programmer.kernel)
  • Re: Polling, Interrupts, DMA, Synchronous, Asynchronous I/O Definitions
    ... > Sorry, but even with blocking, polling is still polling ... > (though blocking makes it less costly). ... > Even though a blocking API is called, the loop is still ... "GetMessage" does with messages, but on the condition of "key ...
    (alt.lang.asm)