I'm writing an app. that launches a separate thread that sits in a
WaitForMultipleObjects call. The first object is a "die" event that is set
by the main thread to terminate the spawned thread, and the sencond is a
file notification event.
The application works fine, except that it's using 99% of my CPU time.
I'm running NT4 with SP4. The application is written in Vis C++ 5, using
MFC. The spawned thread is created using AfxBeginThread.
Any ideas?
Thanks,
Paul.
Paul Perkins wrote in message <7g170g$j...@romeo.logica.co.uk>...
I would guess that you are doing something like this:
while (TRUE) {
if (::WaitForMultipleObjects(nHandleCount, handles, TRUE, 0))
break;
// Do some other stuff.
}
This loop is very tight, and would probably account for the high CPU usage.
Nick Carruthers
PP> Dear All,
PP> I'm writing an app. that launches a separate thread that sits in a
PP> WaitForMultipleObjects call. The first object is a "die" event that is
PP> set by the main thread to terminate the spawned thread, and the sencond
PP> is a file notification event.
PP> The application works fine, except that it's using 99% of my CPU time.
PP> I'm running NT4 with SP4. The application is written in Vis C++ 5, using
PP> MFC. The spawned thread is created using AfxBeginThread.
PP> Any ideas?
You should make sure that you force a time slice by calling Sleep().
Make it a loop. Make it an asychronous call, by using a ZERO wait value.
Don't use INFINITE. Experiment with the sleep value between 15-75 or higher.
You will be surprise at the results. :-)
If his thread is actually waiting it will use no (repeat, no, none,
zero) CPU time. Using sleep(0) will not make it use any less time nor
make it wait any sooner.
His problem is that his wait call isn't actually waiting. Adding
sleep's won't help this.
Furthermore if there are no other threads at his threads's priority,
adding a sleep(0) before the wait will have no effect at all; you
can't "give up the rest of your time slice" if no other threads that
want it.
--- Jamie Hanrahan, Kernel Mode Systems, San Diego CA (j...@cmkrnl.com)
Windows NT drivers, internals, and training
http://www.cmkrnl.com/ NEW! driver resources and FAQ pages
Please post replies, followups, questions, etc., in news, not via e-mail.
>If his thread is actually waiting it will use no (repeat, no, none,
>zero) CPU time. Using sleep(0) will not make it use any less time nor
>make it wait any sooner.
>
>His problem is that his wait call isn't actually waiting. Adding
>sleep's won't help this.
Jamie is right on this - it is the wait that isn't working.
Check what type of event you have created for use in the
WaitForMultipleObjects() call. One possible problem is that one of the events
you are waiting on is _not_ an auto-reset event. This means that the first
time it is signalled, your thread runs. IF the thread does not manually clear
the event then the event is still signalled when the thread loops back to the
WaitForMultipleObjects() call, and so you have a polling loop instead of a
blocking one.
HTH,
AndyM
--
Andy Moreton
Virata Ltd http://www.virata.com/
Mount Pleasant House, Huntingdon Road, Cambridge CB3 0BL, UK
Tel: +44 1223 566919 Fax: +44 1223 566915
On May 04, 1999 09:57am, J...@CMKRNL.COM (JAMIE HANRAHAN) wrote to HECTOR
SANTOS:
>>You should make sure that you force a time slice by calling Sleep().
>>Make it a loop. Make it an asychronous call, by using a ZERO wait value.
>>Don't use INFINITE. Experiment with the sleep value between 15-75 or
>>higher.
JH> If his thread is actually waiting it will use no (repeat, no, none,
JH> zero) CPU time. Using sleep(0) will not make it use any less time
JH> nor make it wait any sooner.
Correct, but I never suggested a Sleep(0)
JH> His problem is that his wait call isn't actually waiting.
Ok, without seeing code...
JH> Adding sleep's won't help this.
Sure it will. Not Sleep(0) though. That could chew up CPU time as well.
JH> Furthermore if there are no other threads at his threads's priority,
JH> adding a sleep(0) before the wait will have no effect at all; you
JH> can't "give up the rest of your time slice" if no other threads that
JH> want it.
Actually, using a Sleep(0) is not optimal. I suggested something
that is a factor of the OS quatum value, 15, 30, 45, etc. A sleep(0) forces
a pre-empt on other threads on the system, and as you say, other
threads may not want it causing unncessary context-switching.
But I agree, if he is not waiting and there is no sleep, that would be 1
explaination for the high cpu usage. He should not have to use a Sleep(x)
and simply wait on the kernel objects.
Andy Moreton wrote in message <1Om*fq...@news.virata.com>...
[Snip]
>
>>If his thread is actually waiting it will use no (repeat, no, none,
>>zero) CPU time. Using sleep(0) will not make it use any less time nor
>>make it wait any sooner.
>>
>>His problem is that his wait call isn't actually waiting. Adding
>>sleep's won't help this.
>
>Jamie is right on this - it is the wait that isn't working.
>
>Check what type of event you have created for use in the
>WaitForMultipleObjects() call. One possible problem is that one of the
events
>you are waiting on is _not_ an auto-reset event. This means that the first
>time it is signalled, your thread runs. IF the thread does not manually
clear
>the event then the event is still signalled when the thread loops back to
the
>WaitForMultipleObjects() call, and so you have a polling loop instead of a
>blocking one.
>
>HTH,
>
> AndyM
>
>--
>Andy Moreton
>Virata Ltd http://www.virata.com/
>Mount Pleasant House, Huntingdon Road, Cambridge CB3 0BL, UK
>Tel: +44 1223 566919 Fax: +44 1223 566915
>
>
Thanks for that, Andy,
Calling ResetEvent (hEvent) sorted out the problem.
I (mistakenly) thought that calling FindNextFileNotification (or whatever -
it's Sunday and I'm at work....) would be clever enough to do this
internally.
All is now working fine, so thanks again to all who have replied to my
message.
Regards,
Paul