Bug in Windows? Changing Priorty Value on Process or Thread does NOTHING!

[quantass]

I was using the SetPriorityClass(..) and SetThreadPriority(..) api's in vc7 and noticed that when i change my process and thread (since each process must have at least 1 thread running i just set the thread priority on this main thread) to THREAD_PRIORITY_IDLE (the lowest possible setting) i notice that when i run my app it STILL eats up ALL of my CPU time --> 95-100%!!!!!

I am using the RegSaveEx(..) api to export out portions of my registry but when i use this api it just HOGS all of my CPU time. Is there a way to reduce the cpu usage by this api in any way? I was hoping that by setting my process and thread priority to idle i would see some kind of difference ... i see NONE.

Thanks for the assitance. :)

[darwen]

I think if you run any other processes on the machine you will notice a difference.

If your thread is running in a tight loop (which it appears it is) and no other processes are running in tight loops then your thread will occupy as much processor time as it wants - there's nothing else around using the processor so why shouldn't it ?

In actual fact Windows schedules processor time to each thread depending on a variety of properties : one of which is priority and another is whether they're requesting large amounts of processor time or not. Most threads operate either through message loops (i.e. windows UI applications) or are waiting on an event to occur. These are in a 'wait' state most of the time, and so therefore occupy very little processor time.

WaitForSingleObject is a typical example of a method which waits around using as little processor time as possible.

So is GetMessage().

If you want to reduce the overhead then put a Sleep statement into your thread. That'll have the desired effect.

And in future don't think "this doesn't work as I think it will - oh, it's Window's fault and there must be a bug". This is EXTREMELY RARE ! It will be 99.9% of times because of either

(1) You don't understand how Windows works.
(2) Your code is wrong.

Don't be so ready to blame Windows for your shortfalls in future. Keep doing that and next you'll be saying things like "I crashed my car into a lamppost and it was the lamppost's fault" or "I'm covered in mud because I fell over, and it's the mud's fault".

It's only ever not YOUR fault when you can prove it. Or at least that's my philosophy.

Darwen.

[quantass]

Hi Darwen...Thanks for the insightful reply!!! Very useful! And a big thanks for the useful advice ... i will defintiely remember that ... all of it!! :) :) :)

[Andreas Masur]

[ Moved thread ]

[Andreas Masur]

darwen already gave you the correct answer, however, I would like to add some comments here as well.

This is a typical example where people try to implement things without understanding the underlying basics. I do not want to offend you but if you are honest you would agree with me.

Multithreading is one of the most complex and most difficult area in programming disregarding the language. Getting the understanding and becoming a professional with multithreading takes quite an amount of time. Unfortunately, unless the application is not running on a multi-CPU machine most errors are not being seen...bringing the same application to a multi-CPU machine might fail badly. And believe me...I have seen many cases, even with the hyperthreading feature of newer Pentium CPU's.

Why is it that way? Simply there is only a smaller amount of people who really have the deep inside one basically needs to understand and overview the whole concept and topic. Creating a multithreaded application which appears to run is simple...however, creating a multithreaded application which actually takes advantage of the multiple threads in order to optimize processing time is far away from being simple.

What I am trying to say is...in order to deal with multithreading one should first understand the concept and the consequences it has before actually trying to do the more advanced stuff (such as trying to influence the scheduler)...

[darwen]

Andreas,

I only have experience of multi-threading on single processor and hyper threading systems. Not multi-processor systems.

So in this respect my knowledge is lacking.

However, I think if you keep to basic rules you can't go far wrong... but I'm hoping you'll correct me if I'm wrong.

(1) Use windows to do the scheduling. I.e. start up threads with normal priority.
(2) Critical section everything that needs to be. In fact, I don't like the MFC CCriticalSection class because it doesn't implement a FIFO queue. Under high loads I've experienced starvation (i.e. threads which are waiting for very long periods of time) in single processor systems.

As to point (2) I've implemented my own critical section class which does a FIFO queue - not using critical sections I might add.

Again I've never dealt with a multi-processor system.

Thanks,

Darwen.

[Andreas Masur]

Well...yes...if one does not play around with all the possible fancy things like priorities and such, there is not that much one can break while creating threads. Eventhough, I still would argue to have at least some basic understanding about threads and what their connection to and in the underlying operating system is. It can be compared to any other thing you want to use....there is not much sense in trying to program an OpenGL 3D game while learning C++...

On single-CPU system, adding threads does not help that much anyway since only one thread can actually run at the same time. Thus, sloppy multithread programming does not cause any severe effects usually. However, overusing threads can reduce the processing time on a single-CPU much worse than the program would have needed while using only one thread.

As to the critical sections...I guess you are referring to the spin count you mentioned in another thread...well, I haven't experienced the problems so far...thus, I cannot say much there...nevertheless, critical sections are good enough in single processes only since they do not work over process boundaries. As long as this rule is being followed, they are sufficient for most of everydays programming jobs.

Again....basic multithreading is not that hard to implement...it is just that it is far more easier to affect your application in a bad way than affecting it in a good way.... :cool:

[OReubens]

I'd also like to note that in the many years I have coded multithreaded programs, I have rarely needed to play with the priority levels.

Exceptions are usually only high priority (or even realtime) threads which are interfacing with hardware and must get data at regular intervals or make the hardware 'free' as soon as possible. Things like reading sensor data and the like often fall in this category. Because the hardware usually only offers you to get a current sensor value, but does not do any caching.
Communication over sockets usually does NOT fall in this category, because the underlying dryvers already do some caching.
Other exceptions are programs/threads which you want to consume all available 'idle' time in the PC. This is (among others) usefull for processing that takes extremely long times (hours/days). Because it will allow to get the job done, while interfering with the user still working at the PC as little as possible.

The only case where I ever needed to boost priority was an app that does process control of a product line in a manufacturing plant. The production line must get it's time. But updating the screen was less important, so the UI painting thread had lower priority. But when the user forced a refresh (F5), priority had to be boosted above that of the process control thread temporarily (with the possible chance that the production line got a reset in the process).

For 98% of the apps, you can leave the thread/process priority at normal.


For the rest I have to agree with Andreas. Multithreading in many ways is an easy topic. But implementing multithreading in such a way that you actually get a benefit can be extremely difficult. The problem is that there are very few books/documentation available for 'advanced' multithreading. Most books only cover the basics.

[darwen]

Personally I always adhere to this rule :

Adding multithreaded functionality adds an order of magnitude of complexity to produce a stable application.

I've yet to be proven wrong.

Personally, I only use threading when I absolutely, totally, completely and wholly need to.

Debugging multi-threaded applications gives me a headache like nothing else.

Recommendation:

Only use it if you really need to. Then think again. Then rethink. Then go home, sleep on it for 2 days and think again.

Once threading is introduced into an application the problems you encounter with single threaded applications are insignificant...

And that applies to when you know what you're doing !

Also threading needs to be a design decision made right from the start of any application.

If it isn't I've learned (to my detrement) that it's hugely more difficult to make a single-threaded server multi-threaded after the fact.

Sorry, I'm going on a bit now so I'll stop.

Darwen.

[OReubens]

I only have experience of multi-threading on single processor and hyper threading systems. Not multi-processor systems.

Hyperthreaded systems are not entirely like a real Multi CPU machine.
Some typocal problems with multithreading on a multiCPU machine do not occur under a hyperthreaded (1 real CPU) system.
A read/modify/store on a single aligned variable is atomic on a hyperthreaded machine but isn't on a multi CPU machine.


(2) Critical section everything that needs to be. In fact, I don't like the MFC CCriticalSection class because it doesn't implement a FIFO queue. Under high loads I've experienced starvation (i.e. threads which are waiting for very long periods of time) in single processor systems.
CriticalSection isn't supposed to offer FIFO. if you have lots of threads waiting for a specific CS, then either of them can get a lock when the CS becomes available.

It is a bad idea though to have too many threads wait on the same CSs (or any synchronisation object for that matter). The whole point of multithreading is getting higher throughput. If you have many threads waiting on eachother, you basically have a (serious) design flaw.

[darwen]

I believe I already said that I don't have any experience on multi-processor systems and was just stating the experience I have on single processor systems.

I agree that threading is just a way of getting the most out of the processor/s.

But don't you agree with my previous post which said that adding threading to an application increases the complexity of producing a stable application by an order of magnitude ?

Darwen.

[Andreas Masur]

Adding multithreaded functionality adds an order of magnitude of complexity to produce a stable application.
This is of course true....but this is actually what I like about it...I like to step through my multithreaded applications in my brain with closed eyes to actually figure out why the heck this or that does not work as it should according to my design...on the other side...many people would call me weird anyway... :eek:

And that applies to when you know what you're doing !
Well...yes...but it becomes more easy once you know what happens under the hood... :cool:

Also threading needs to be a design decision made right from the start of any application.
Well...of course...but that basically needs to be done with the whole application in the first place as well. I agree though, that some things such as threading, exception handling should be designed before the programming actually starts...

[darwen]

Actually Andreas I agree with you.

Working out why a multi-threaded application falls over is really challenging, and when you get it right is exceptionally rewarding because of the speed you can get out of it. After several Paracetamols to get rid of the headache of course... *laugh*.

It's amazing really what you can do with even a normal PC as a server with multi-threading when you get it right.

Thumbs up, definately.

:thumb:

Darwen.

[darwen]

Of course we've yet to touch on the subject of COM in a multi-threaded environment... but I believe this thread is starting to get off subject.

Darwen.