Re: Re-entrancy???

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


"Bill McCarthy" <Bill@xxxxxxxxxxxxx> schrieb im Newsbeitrag
news:OmzCpCDUJHA.5408@xxxxxxxxxxxxxxxxxxxxxxx

"Schmidt" <sss@xxxxxxxxx> wrote in message
news:OMXEZ0%23TJHA.1908@xxxxxxxxxxxxxxxxxxxxxxx

"Bill McCarthy" <Bill@xxxxxxxxxxxxx> schrieb im Newsbeitrag
news:eNaiHp9TJHA.1172@xxxxxxxxxxxxxxxxxxxxxxx

I'm not going to argue, it is a no-brainer to see the
difference in the CPU usage

IOW: you are literally just slowing down your own
application for *zero* benefit to any other application.
Please stop giving such wrong advise here.

One should only enter a "pure DoEvents-Waitloop", if
he is very sure, that the maximum-looptime is not larger
than - let's say - 100ms.
In every other scenario you should definitely add
an additional Sleep-Call into your WaitLoop - period.


Nonsense.
Of course not.
Your recommendation reads (in the meantime), that
additional Sleep-Calls in DoEvents-based waitloops
have to be avoided generally.
And that is just plain wrong.
Read the above again - I've already wrote a comment
about really short WaitIntervals - and these can of
course be coded without an additional sleep, just with
the pure DoEvents in it.

If I'm doing a calculation intensive routine adding *additional*
Sleep calls will just slow the application down.
IMO that is the nonsense.
An additional Sleep-Call (in a longer running, or even
continuously running DoEvents-Loop) does not "slow
down" your whole Application, it just offers a "more relaxed"
Waiting-behaviour with a more "diskrete" Entry-Interval
for UserEvents (Win-Messages). Each "Code-cascade",
which is/was triggered from these UserEvents then runs
of course at full speed until it is finished and the App
enters again its (more discrete) Idle-State.

A doEvents call is important however as it does allow
you app to run at full speed while allowing for user input
such as cancel, ...
Of course, and with an additional Sleep-Call you only
change the behaviour of the "Cancel-Case", which then
can only "react" within the Interval you specified within
your additional Sleep-Call (16msec on most systems, if
not paired with the timeXXX-Apis) - but all callstacks
which are triggered from the Win-Message-Pump run
of course at full-speed.

and allows for other windows application time sharing.
The additional Sleep-Call does not change this behaviour.

If you don't do so, then you are wasting a huge amount
of CPU-cycles (which are wasted in checking the
message-queue over and over again, with a frequency
of ca. 350000 MessageQueue-Checks per second -
and that is, what is causing the huge processor-load, not
the implicite Sleep 0 Call which is also performed under
the hood).

Whether or not PeekMessage is occuring in DoEvents
has no impact on the overall CPU utilization.
A loop without delays will run at full CPU.
PeekMessage has nothing to do with that.
Glad you admit finally, that it is bad behaviour, to code
endless-loops within your App, which stress the CPU
fully and do nothing but "wait".
I've mentioned the MessageQueue-Checking-Code,
because these calls (in case of a DoEvents-Endless-loop)
simply cause the main-percentage *within* your 100%-
CPUCore-utilization. This is of course always at max.
in each endless-loop that does not call a system-waitfunction
internally - no need to mention that - and no, before you come
up with that - Sleep with a 0-Param behaves *not* like a
system-waitfunction.

But you are of course free, to code your Wait-Loops
in any way you want, but don't wonder, when your
Notbook-Bat is empty after only half an hour and your
CPU-fan "goes nuts".

I would be surprised to see people using PLC's off a
notebook running on it's batteries, at least not in any
continual mode, which is what you are arguing.
I doubt very much his polling is continuous. The code he
showed should exit very quickly.
Then he's fine - but your comments suggest, as if it would
be a good idea, to avoid additional Sleep-Calls in longer
running DoEvents-scenarios generally.

All others should definitely follow Larrys or Eduardos
advise, to add a Sleep 1 - call.

No they should not.
Yes, they should - again, this is wrong advise.

You use sleep if you need to wait for a defined period.
Yep, exactly what we want to achieve here.

Sleep 1 is misleading, as has been clearly demonstrated
in this thread by those who have said it will return in 1 or 2
milliseconds.
Sleep will return definitely within 1 or 2msec, when coded
correctly, using the timeXXXX-APIs.
If this knowledge about appropriate WinAPI-usage was
not available in your repertoire, then don't blame others
who know better.

They should write Sleep 10 or Sleep 20, and then people will
get a true sense of what is happening.
Why?
Sleep 1 (without the timeXXXX-APIs) is an attempt, which
can succeed on other systems which support a lower system-
resolution "out of the box" (maybe an appropriately configured
XP-embedded for example).
Or on Linux/Wine I don't have to call the timeXXXX-APIs
explicitely - the system-resolution of the newer 2.6-kernels
supports 1msec out of the box - and maybe Windows7 will
do so too by default.

Whether or not a delay is appropriate for your app is another
thing. For polling a PLC there is no need to do that as part
of the polling.
As said, if done only for a really short wait-interval, one
should have no problems with that.
For *continuous* polling (ensuring 1-2msec react-time), the
timeXXX-APIs paired with Sleep 1 are the better choice
(in case 1-2ms are small enough - if not, then a threaded
approach would help).

Olaf


.

Relevant Pages

  • Re: Re-entrancy???
    ... If I'm doing a calculation intensive routine adding *additional* Sleep calls will just slow the application down. ... A doEvents call is important however as it does allow you app to run at full speed while allowing for user input such as cancel, and allows for other windows application time sharing. ... Whether or not PeekMessage is occuring in DoEvents has no impact on the overall CPU utilization. ... For polling a PLC there is no need to do that as part of the polling. ...
    (microsoft.public.vb.general.discussion)
  • Re: Are busy loops bad?
    ... I thought Sleep effectively was done in DoEvents. ... What's the diff? ... You'll still show a 100% CPU without Sleep, even though it'll be a *very* responsive ...
    (microsoft.public.vb.general.discussion)
  • Re: cpufreq est and Enhanced Sleep (Cx) States for Intel Core and above
    ... Adam McDougall wrote: ... >> Another thing I wish could work is the Enhanced cpu Sleep States; ... The major reason being that the acpi cpu> driver does not support well multiprocessor systems. ... I've not updated the patch since then so> it might or might not apply cleanly to a recent current. ...
    (freebsd-current)
  • Re: cpufreq est and Enhanced Sleep (Cx) States for Intel Core and above
    ... > Another thing I wish could work is the Enhanced cpu Sleep States; ... > this Dell Latitude D820 laptop only sees C1 although the document ... > acpi stuff and/or verbose boot logs if it would be helpful. ...
    (freebsd-current)
  • Re: Batch file and MFC (Properly Terminating Application)
    ... I have a function called DoEvents ... Sleep fucntion is within that loop as well as DoEvents ... while(!GetQueuedCompletionStatus(port, &bytes, &key, timeout)) ... if timeout also check for abort ...
    (microsoft.public.vc.mfc)