Re: Continuous loop handling
From: Jerry Coffin (jcoffin_at_taeus.us)
Date: 04/25/04
- Next message: Todd L. Peters: "Help Problems"
- Previous message: Ian Semmel: "Re: Making a new MFC build"
- In reply to: beauwlf: "Continuous loop handling"
- Messages sorted by: [ date ] [ thread ]
Date: Sun, 25 Apr 2004 10:47:53 -0600
In article <c6gl4u$6lr$1@news4.jaring.my>, jamesg@pd.jaring.my
says...
> Hi Group
>
> I am executing a function in my program each time there is a external
> hardware trigger. Currently I am using a worker thread to continuously
> monitor the hardware input in a while loop. Tough my gui is active by this
> mechanism, but my cpu usage time is always 100%. and my GUI does get a
> little sluggish.
>
> How to improve this mechanism, I feel it is not efficient to let my cpu time
> be used 100% by my program. Is there a way to free up the cpu time
> especially during
> the ..wait for hardware trigger to change '0' loop.
Ideally, the device driver for your hardware would do something like
signal an Event when the input takes place, even just provide a file
for you to read from that'll block until there's data to read.
Barring that, you've got a couple of choices. One would be to call
Sleep somewhere inside your loop. The number you pass as the argument
is (roughly) the number of milliseconds before your loop will
continue, and normally works in 10 ms increments, so if you can allow
a change to go unnoticed for around 100 ms, Sleep(100) will do that,
and reduce your CPU load to nearly 0. This will make the thread in
which you're doing the checking take less CPU time, but if it's the
same thread as you're using to implement your GUI, it'll cause a
problem: during the Sleep time, you can't process messages either, so
while this will reduce CPU usage, it'll probably make the GUI of that
program even LESS responsive (though it'll make other programs far
more responsive).
If you're doing this in the same thread as the GUI, it's probably
better not to check the value in an explicit loop at all. Instead,
set a time for a reasonable interval and check the value in response
to the timer -- and then if it's changed, you usually want to post
another message back to your own queue saying there's something to
process.
Whether that's a good solution or not depends heavily on how quickly
you need to respond to the hardware event -- timers aren't
necessarily particularly prompt, and posting a message back to your
own queue CAN result in a fairly long (e.g. 100 ms) delay as well.
One way to help is to use a multimedia timer instead -- you can
usually expect them to respond within a ms of when you ask for.
Another possibility would be to move the code into a separate thread.
This isn't a panacea, but it can make it a lot easier to govern how
much CPU usage is devoted to that task. For one example, you can set
the loop to run like you're doing right now, but set the thread to
lowest priority. This means the thread will get all the CPU time as
long as there's nothing else ready to execute, but no CPU time if
anything else can run.
--
Later,
Jerry.
The universe is a figment of its own imagination.
- Next message: Todd L. Peters: "Help Problems"
- Previous message: Ian Semmel: "Re: Making a new MFC build"
- In reply to: beauwlf: "Continuous loop handling"
- Messages sorted by: [ date ] [ thread ]
Relevant Pages
|
