Начнем с того, что процессор не будет работать быстрее от того, что у нити повышен приоритет. Не стоит об этом забывать.

Повышение приоритета нити, которая выполняет большую работу процессором, приведет к тому, что UI будет перерисовываться рывками (только по starvation prevention в кернеле). Юзеры за это спасибо не скажут.

Если все сделано правильно и не наложены искусственные лимиты (по требованиям заказчиков, например, чтобы не было 100% процессора) — то можно добиться того, что и низкоприоритетная нить будет иметь почти 100% процессора, конечно, при условии, что с машиной ничего больше не делают.

А вот если вся работа нити состоит в "получить реквест — исполнить его, сделав disk/network IO — ждать следующего" — вот тут повышение приоритета очень полезно.

Дело в том, что, если такая нить будет иметь обычный приоритет, то возможно, что в промежутке между получением и исполнением реквеста ее прервут. Прервут более высокоприоритетной нитью, и не исключено, что после этого перед возвратом в нее выполнится еще парочка равных по приоритету нитей.

Это приведет к большой задержке между получением и исполнением реквеста.

Если же дать такой нити высокий приоритет — то ее мало кто прервет в самом интересном месте. И негативного эффекта на систему в целом не будет — ей все равно вот-вот блокироваться в вызове, который и есть исполнение реквеста. Заблокируется и отдаст процессор, а реквест тем временем уже бежит — на RPC сервере, на SQL сервере, или же на железке диска.

Это описано еще в классической книге Дейтела про ОС — CPU-bound нитям приоритет пониже, IO-bound — повыше.

Еще надо упомянуть инверсию приоритета. Возникает она при наличии защищенных локом данных, к которым обращаются 2 нити разного приоритета.

Допустим, низкоприоритетная нить A взяла лок, начала трогать данные, и тут ее прервали — например, завершением IO, которое как правило дает priority boost. А там, возможно, еще парочка равных по приоритету нитей побегать успела.

Все это время высокоприоритетная нить B, которая тоже хочет работать с данными, стоит на захваченном локе.

Вот это называется "инверсия приоритета". Тормоза создает — очень даже заметные.

Как избежать: решить для себя, каков наибольший приоритет, с которого будет браться данный лок. И всем остальным нитям поднять приоритет до этой отметки перед взятием лока и на время работы с залоканными данными. Снизить обратно после освобождения лока.