Re: Virus alert on my app??

Tech-Archive recommends: Repair Windows Errors & Optimize Windows Performance

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


.

Relevant Pages

  • Re: Virus alert on my app??
    ... Static Busy As Boolean ... DoEvents does actually call Sleepbut either of them in a closed loop will still result in the processor running at full 100% usage whether another process is waiting for processor time or not. ... This is because although both DoEvents and Sleepdo 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. ... 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 Sleepis 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, causing the processor to almost immediately be given back to the other app. ...
    (microsoft.public.vb.general.discussion)
  • Re: Form refresh in VB6
    ... that won't fix the problem. ... problem is that your VB app is executing a block of code ... every so often in your loop you need to use the "DoEvents" command. ...
    (comp.lang.basic.visual.misc)
  • Re: EnableVisualStyles and DoEvents
    ... >the user while the loop is executing. ... This way, DoEvents is not needed. ... > The reason for my interest is when DoEvents is called from within a long ... loop in order for an app to respond to the user while the loop is executing. ...
    (microsoft.public.dotnet.languages.vb)
  • Re: interprocess communication
    ... I think you need a loop that continues until the desired message has been received, or the data has been suitably changed, or some longish time interval has elapsed with no response. ... The loop body could be as simple as DoEvents, CheckData; or Sleep 500 ms, DoEvents, CheckData; or WaitMessage, DoEvents, CheckData; etc. ... A single DoEvents is too short to allow the other app to send the answer AND the first app to receive the answer. ... I could veryfy that the receiving app fired its answer **before** the second request was received, so it's a problem of the sending thread. ...
    (microsoft.public.vb.general.discussion)
  • Re: Re-entrancy???
    ... VB app and does not care what it does with them. ... Windows allots a stream of "time slots", each of a specific maximum period, to your VB app and to all other running processes / threads, with each slot being limited to a maximum time of perhaps a few milliseconds or more depending on the OS version and various other things. ... Once your own app has been allotted a time slot then if it is very busy (processing some code in a tight loop for example) your app will continue to use the processor more or less continuously until the full period of the time slot has elapsed. ...
    (microsoft.public.vb.general.discussion)