Thread Priority Question

[jrohde]

Hello all,

Just curious about the nature of thread priority. I currently use Win32 threads, but I suppose this would apply to any API or OS:

In a file splitter application I wrote, the splitting operation takes place in a worker thread, while the main UI thread is of course allowed to do other things (cancel, pause, etc.). I have never really thought about thread priority until now. From MSDN's documentation on thread priority, it appears that this may not be as big of a deal as I initially thought, but here's what I'd like to know:

1) If my application is the only thing running, or a few other more-or-less idle programs are running, does it even really matter what priority my worker thread has?

2) If many other applications/processes/threads are occurring, what is the effect? I know it depends on the priorities of the other processes, but let's say I had multiple programs, all running at normal priority levels. Is it advantageous for me to set my worker thread's priority to above normal, or highest? Conversely, if I wanted to hog as little CPU as possible, would I want to set low priority?

The reason for my question is that, if it does matter, I'll start the thread with a certain priority level, and implement a drop-down list to allow the user the change the priority if desired (at which point the program will suspend/update/resume the thread, and continue). If it's pointless or overkill, I won't. I have seen this in other programs like CD burners, but I'm not sure the same rationale would apply to simply copying and writing (large) files.

Thanks in advance!

[kbw]

Don't change priority unless you have good reason to. A lot of man years has gone into tuning the OS scheduler.

In answer to your questions,
1. It does matter what priority your thread has.
2. If you bump up the priority of your thread, you're most likely not to see any improvement for that thread but you'll adversly affect the rest of the system. Again, leave the scheduling priorities alone, the OS changes the piority as it goes and in general, does what's best.

[helios]

If there's more CPU than all the threads need, priority is irrelevant because all threads will get what they need, and the rest of the time the CPU will idle. Priority is relevant only when there's one or more threads capable of using the entire CPU (for example, a number crunching application). Typically, at the highest priority, the thread gets all the time it needs until it yields or terminates (I think this priority is reserved for the kernel), and at the lowest priority, the thread only gets time when no other thread is running. Threads with the same priority get similar amounts of time, and threads with higher priority get more time.

For most applications, it's better to leave the priority to the default and let the OS handle time sharing. Not to mention that you may not even be able to set the priority for security reasons.
There are exceptions, though. For example, distributed computing projects like Folding@Home or GIMPS set their priorities to the lowest to avoid grinding the entire system to a halt, while system monitors like Process Explorer are set higher priorities.

[jrohde]

Thanks to both of you.

@kbw: That sort of confirms what I had started to think. I did run a test on it just for my own curiosities, and I didn't notice any significant effect at 5 different priorities, at least not with only my application and a web browser running. I don't see any reason to mess with it myself.

@helios: Yeah, you're right about the kernel's priority - I recall MSDN mentioning that specifically. Levels 16-31, if I remember correctly, are supposed to be reserved for what's called "real time" priority, like input/output devices, or other hardware. Stuff I would never think about interfering with anyway, even if the system allowed it.

[ktoto256]

1. It does matter what priority your thread has.

Does it? When all other threads are in wait state, isn't all the CPU time given to our thread?