-
January 14th, 2015, 08:06 AM
#16
Re: CPU at 100% when using AfxBeginThread
if your worker threads cause your UI the be unresponsive...
1) you're messing around with thread priorities in an inapropriate manner.
2) you have a design/conceptual issue where your worker thread is hard-blocking the UI, OR the UI is blocking on a result from a thread that isn't coming.
3) your worker threads are posting so many messages to the UI thread that the UI can't process them all in a timely manner. This too is a design issue.
I can have 100 worker threads all doing heavy calculations and IO with all CPU cores at 100% and this will have (almost) zero effect on the UI thread if I have my priorities right and am not causing UI blocks.
as to the code you posted...
you're passing the same 'this' (I'm assuming that's a CSerialCom instance) to 2 threads.
you pretty much expecting this CSerialCom class to be thread safe at the function level. That could be the case, but it would be somewhat rare if it was implemented that way. It's highly unusual for a serial comm class to be implemented that way.
-
January 14th, 2015, 08:08 AM
#17
Re: CPU at 100% when using AfxBeginThread
Originally Posted by 2kaud
Go Advanced, select the code and click '#'. You'll then see the code tags added so that the code is formatted properly when displayed.
Thanks. Didn't realize that. First time using a post here.
-
January 14th, 2015, 12:48 PM
#18
Re: CPU at 100% when using AfxBeginThread
Originally Posted by 2kaud
From the OP post #1, it fails on low end systems (Duo Core2, 5 GB Ram) but works on powerful systems (Core i7, quad core, 28GB Ram). Assuming this isn't a memory thrashing issue (memory usage is said by the OP to be stable), it seems that if the threads run on their own core then its ok but if threads share a core it doesn't.
On the powerful system that works, what are the various core utilisations?
It still could be a underlying issue with thread safety. Maybe I'm reaching but on slower machines there could be more contention (and more opportunity for race conditions). I would also be interested in handle counts while running to see if those might be increasing.
-
January 14th, 2015, 12:51 PM
#19
Re: CPU at 100% when using AfxBeginThread
Originally Posted by OReubens
3) your worker threads are posting so many messages to the UI thread that the UI can't process them all in a timely manner.
If the OP is using PostMessage, this won't cause the threads to slow down. Of course, using SendMessage in this manner would be a different story.
-
January 14th, 2015, 12:56 PM
#20
Re: CPU at 100% when using AfxBeginThread
Originally Posted by Arjay
If the OP is using PostMessage, this won't cause the threads to slow down. Of course, using SendMessage in this manner would be a different story.
No, not sending or even doing much posting of messages. Any messages sent is via PostMessage, not SendMessage.
-
January 14th, 2015, 01:01 PM
#21
Re: CPU at 100% when using AfxBeginThread
Originally Posted by WildWill
No, not sending or even doing much posting of messages. Any messages sent is via PostMessage, not SendMessage.
Do the handle counts increase? What is the actual implementation that you use for the serial port communication? Are you able to create multiple instances of this class (if it is a class) without running into thread safety issues?
Are you creating/destroying instances of objects/threads in the course of operations where you may not be cleaning up resources properly.
In general, a system that slows down over time indicates resource leaks which may be more pronounced (noticeable) on slower systems.
-
February 10th, 2015, 04:41 AM
#22
Re: CPU at 100% when using AfxBeginThread
Originally Posted by Arjay
100% will often result in a non-responsive UI - not too cool if a user is logged on and trying to use the system. For folks new to multi-threaded programming, pegged cpu's could be an indication of doing something wrong.
Fully agree
-
February 10th, 2015, 08:27 AM
#23
Re: CPU at 100% when using AfxBeginThread
Originally Posted by Alex_41
Fully agree
BUt the Two are unrelated.
it is perfectly possible to have the CPU's at 100% and have a perfectly fine responsive app. In fact that is the situation to strive for.
A badly written MT app may cause the UI to be unresponsive and this can happen regardless of the CPU being at 100% or not. You can have a badly responsive app with the CPU being 0%.
So I disagree. pegged CPU's are not a (good) indication of doing something wrong.
A thread not producing results within expected time is an indication of doing something wrong (which is the same as it would be for a single threaded app).
THe UI being unresponsive or hanging is an indication of doing something wrong
-
February 10th, 2015, 08:27 AM
#24
Re: CPU at 100% when using AfxBeginThread
All of what you all say is good advice and reasonable but non of it is valid in this case. Handles don't increase, all resources are cleaned up (and Deleaker doesn't find anything leaking.) It is not a "slow leak", this runs a few seconds and is at 100% CPU usage.
Thanks all.
-
February 23rd, 2015, 04:41 AM
#25
Re: CPU at 100% when using AfxBeginThread
Originally Posted by WildWill
All of what you all say is good advice and reasonable but non of it is valid in this case. Handles don't increase, all resources are cleaned up (and Deleaker doesn't find anything leaking.) It is not a "slow leak", this runs a few seconds and is at 100% CPU usage.
Thanks all.
May be you found a solution in the meanwhile.
I had the same problem when porting a program from visual Studio 6.0 to 2005.
The threads were started wiwth AfxBeginThread and the Sleep() function was used to
make the timing. On using the CreateThread Function all was fine.
As I think using Sleep() is allways a bad solution to do thrad timing, or evan at all
I searched for an alternative.
So trie out finding the WaitableTimer in the Microsoft dokumentation and try using this!
I would advice you never using Sleep() but real Timer functions or event driven synchronization.
Hope it helps
-
February 23rd, 2015, 08:05 AM
#26
Re: CPU at 100% when using AfxBeginThread
Sleep() (or any other method for achieving the same such as long for-loops) is bad in production code for just about anything other than
1) testing purposes (to simulate a lengthy process or delay somewhere in the chain)
2) slowing down retries when synchronising over a LAN/internet if there is no better suited alternative.
Typically speaking the code should run equally well without the Sleep() or with any random amount of delay in there. (in the case of 2, it may cause the CPU usage and network usage to spike, this may be undesirable, but it WILL work).
Delays are sometimes necessary when dealing with hardware at low level, but then we're talking about driver development which is a totally different beast.
Any Sleep() that "has to be there or the code doesn't work" means you have a technical issue in your code that you really should fix.
Any Sleep() that needs to have a very specific value means you have a technical issue in your code that you really should fix.
-
February 24th, 2015, 10:00 AM
#27
Re: CPU at 100% when using AfxBeginThread
May be I didn´t explain exactly enough what I ment.
Please go into your debuger with yout thread where you have placed your Sleep function.
And see what happens when the debugger tries to execute the Sleep function.
In my case the Sleep function acted just like an empty line. It´s strange, I know. Also for me.
So I put the WaitableTimer as an replacement for the Sleep function an it worked.
I also had other threads in my application that were startes through the CreateThread Methode.
In this case I had no problems with CPU overload.
Also there exists another type of Sleep the SleepEx function.
May be this one acts different and work too?
The WaitableTimer is a real timer Sleep is strange. Write it as a replacement for Sleep
You will find stuff at msdn.
Someone wrote an article about:
https://randomascii.wordpress.com/20...-investigated/
And may be this helps too:
http://www.codeproject.com/Articles/...imers-Tutorial
And there are different ways of better use for timers sa a replacement of Sleep.
Watch out for them.
-
February 25th, 2015, 08:21 AM
#28
Re: CPU at 100% when using AfxBeginThread
It doesn't matter how you do the sleep...
If your code has a "hard" wait in it programmed as a Sleep, SleepEx, for-loop, while-loop, waitable timer, counting sheep, waiting for you to finish making a pot of cofee, that serves no other purpose other than to get the very same effect of Sleep(), then my post in #26 applies.
A Sleep in any form is still a Sleep.
Posting Permissions
- You may not post new threads
- You may not post replies
- You may not post attachments
- You may not edit your posts
-
Forum Rules
|
Click Here to Expand Forum to Full Width
|