Why *not* change the priority of a ThreadPool (or Task) thread?

Question

There are many places across the web and Stack Overflow where one is discouraged from changing the priority of a ThreadPool thread or TPL Task. In particular:

"You have no control over the state and priority of a thread pool thread."
"The runtime manages the thread pool. You have no control over the scheduling of the thread, nor can you change the thread's priority."

"You should not change the Culture or Priority or... of a PoolThread. Just like you don't paint or re-decorate a rental car."

"There are several scenarios in which it is appropriate to create and manage your own threads instead of using thread pool threads: (such as...) You require a thread to have a particular priority."

"Each thread in ThreadPool runs at the default priority and the code to change the ThreadPriority has no effect."

However, it is a simple matter to do so, and the debugger shows that the change does seem to stick (insofar as the value can be read back).

Thread.CurrentThread.Priority = ThreadPriority.AboveNormal;

So the question is, what is the specific reason for this particular taboo?

My suspicion: doing so disturbs the delicate load balancing-assumptions of the pool. But this doesn't explain why some sources say that you can't change it.

Answer 1

Lowering the priority could also lead to unexpected consequences.

Imagine you schedule a task in an application, but also call into a library that schedules several other tasks. Say you lower the thread priority while the app task runs. You could then end up with the normal priority tasks in the lib waiting for that low priority task to finish, if the pool doesn't spawn many threads, but the low priority thread it may not be given much CPU time if the rest of the system has many normal priority threads that want to run.

Increasing the number of pool threads would alleviate this, at the cost of wasting more memory on stacks and spending more CPU time on context switches.

Answer 2

It's discouraged, specially if you're upping the priority, because it can affect the overall performance of your system.

Not to offer an overcomplicated answer, but in general, thread priority is a complex topic. For example, Windows has 2 related descriptors: thread priority and process priority. Both range from Idle, the lowest, to Time critical, the highest. When you start a new process, it's set to the default, the mid-range (a normal process priority with a normal thread priority).

Plus, thread priorities are relative, meaning that even setting a thread's priority to the highest in a busy system won't ensure that it will run in 'real-time'. DotNET offers no guarantees on this, neither does Windows. From that you can see why it's better to leave the threadpool alone, since, 99.9% of the time, it knows best :)

All that said, it's ok to lower a thread's priority if the task involves a long computation. This won't affect other processes.

Increasing priority, however, should only be done for tasks that need to react quickly, and have a short execution time, because this can negatively affect other processes.

Answer 3

I've done some experimentation with a reduced-size thread pool which seems to indicate that the thread's priority is reset back to normal once returned to the pool. This resource on threading seems to confirm it. So the effect seems to be very limited even if you do.

Answer 4

If you do change anything, use try/finally to make sure you leave it as you found it.

Answer 5

The thread pool, especially the .NET 4.0 thread pool, has many tricks up its sleeve and is a rather complicated system. Add in tasks and task schedulers and work stealing and all sorts of other things and the reality is you don't know what is going on. The thread pool may notice that your task is waiting on I/O and decide to schedule something quick on your task or suspend your thread to run something of higher priority. Your thread may somehow be a dependency for a higher-priority thread (that you may or may not be aware of) and end up causing a deadlock. Your thread may die in some abnormal way and be unable to restore priority.

If you have a long-running task such that you think it would be best that your thread have a lower priority then the thread pool probably isn't for you. While the algorithms have been improved in .NET 4.0, it is still best used for short-lived tasks where the cost of creating a new thread is disproportional to the length of the task. If your task runs for more than a second or two the cost of creating a new thread is insignificant (although management might be annoying).

Answer 6

You certainly can change it if you really want to, but given that the thread pool threads are re-used, the next code that runs might not expect the change.