Re: Virus alert on my app??

Hi Mike --

DoEvents does actually call Sleep(0)

What I find interesting is that I've never seen it used in a "API-equivalent" of
DoEvents. What evidence do we actually have this is happening? I don't doubt it
may be, but it's never been conclusively demonstratd to me.

This of course cannot be helped if your app
really does want to make full use of the processor in some kind of loop,
perhaps to perform some heavy number crunching or something, but it is a
waste of battery energy if your app is merely polling something in a loop
waiting for something to happen. In such cases it is wise to use a Sleep 1
(or some greater value) which will cause your app to effectively refuse the
processor after it has offered it up until at least one time slot period has
elapsed, or in the OP's case until 100 milliseconds has elapsed, thereby
allowing the processor to run at a very small percentage usage if nothing
else is making heavy demands on it.

Couldn't agree more. I'd be *embarrassed* to offer code that "pegged" the processor
when it wasn't doing anything but waiting. That's just too lame, whether it's a
laptop, desktop, workstation, or server! Anyone doing that oughta be ashamed.

Thanks... Karl




Mike Williams wrote:
"Karl E. Peterson" <karl@xxxxxxxx> wrote in message
news:%23O38DYJYJHA.5336@xxxxxxxxxxxxxxxxxxxxxxx

Private Sub Command1_Click()
Static Busy As Boolean
Busy = Not Busy
If Busy Then
Do
DoEvents
If Check1.Value Then Call Sleep(1)
Loop While Busy
End If
End Sub New form, command button and checkbox. Run, press Command1,
watch taskmgr (Performance tab), click Check1, watch taskmgr.

DoEvents does actually call Sleep(0) but either of them in a closed loop
will still result in the processor running at full 100% usage (in the
simplified example of a single core machine) whether another process is
waiting for processor time or not. This is because although both DoEvents
and Sleep(0) do actually yield the processor, allowing the OS to immediately
offer the rest of your current time slot to any other process that is
waiting for processor time, if nothing else is actually waiting for the
processor at that time then the OS will almost immediately give the time
slot back to your own process, which is then effectively next in the queue
and asking for processor time. So your closed loop with its DoEvents or
Sleep(0) will cause the processor (on a single core machine for simplicity)
to run at 100% usage whilst your loop is running, whether any other process
is making demands on the processor or not.

This doesn't actually slow down any other process that might want to make
heavy continual use of the processor while your closed loop with DoEvents or
Sleep(0) is running because each time your VB app yields the processor that
other app will take up the rest of the time slot and when that app's time
slot finishes and your own app is offered the processor it will accept it
and then almost immediately issue a DoEvents or a Sleep(0), causing the
processor to almost immediately be given back to the other app. So, in such
circumstances, the other app that is requesting continual use of the
processor will run just as fast as it would have done if your own VB loop
had not been running.

However, the processor will continue to run at 100% (in this example of a
single core machine), even when the other app finishes, whilst your loop is
running. At first sight that doesn't sound too bad because your own app only
hogs the processor when nothing else requires to use it, but on laptops that
are designed to "clock down" the processor to a lower frequency when it is
lightly used in order to conserve battery energy the clock down will not
occur whilst your loop is running, thereby causing the battery to discharge
itself long before it would otherwise have done so. At least that's how it
used to work when I was a lad! This of course cannot be helped if your app
really does want to make full use of the processor in some kind of loop,
perhaps to perform some heavy number crunching or something, but it is a
waste of battery energy if your app is merely polling something in a loop
waiting for something to happen. In such cases it is wise to use a Sleep 1
(or some greater value) which will cause your app to effectively refuse the
processor after it has offered it up until at least one time slot period has
elapsed, or in the OP's case until 100 milliseconds has elapsed, thereby
allowing the processor to run at a very small percentage usage if nothing
else is making heavy demands on it.

Mike

--
..NET: It's About Trust!
http://vfred.mvps.org


.

Loading