Toute relation entre la priorité du processus et la priorité du pool de threads (C #)

Je comprends que le processus en cours d’exécution modifie / ne peut pas modifier la priorité du pool de threads, mais la priorité d’une tâche particulière exécutée sur le pool de threads est-elle facturée à un prix correspondant à celui du processus d’appel?

En d’autres termes, toutes les tâches du pool de threads sont-elles exécutées avec la même priorité, quelle que soit la priorité du processus d’appel?

Je vous remercie

mise à jour 1: j’aurais dû être plus spécifique, je me réfère à thread dans Parallel.ForEach

Je comprends que la priorité du pool de threads ne doit pas / ne peut pas être modifiée par le processus en cours,

Ce n’est pas exact Vous pouvez modifier la priorité de thread du pool de threads (à l’intérieur du délégué lui-même) et il s’exécutera avec une nouvelle priorité, mais la priorité par défaut sera restaurée à la fin de la tâche et renvoyée au pool.

ThreadPool.QueueUserWorkItem(delegate(object state) { Thread.CurrentThread.Priority = ThreadPriority.Highest; // Code in this function will run with Highest priority }); 

la priorité d’une tâche particulière exécutée sur le pool de threads est-elle intégrée à la priorité du processus d’appel?

Oui, et cela ne s’applique pas uniquement aux threads du pool de threads. Dans le processus Windows, la priorité est donnée par sa classe (de IDLE_PRIORITY_CLASS à IDLE_PRIORITY_CLASS ). Avec la priorité du thread (de THREAD_PRIORITY_IDLE à THREAD_PRIORITY_TIME_CRITICAL ), il sera utilisé pour calculer la priorité finale du thread.

De MSDN:

La classe de priorité de processus et le niveau de priorité de thread sont combinés pour former la priorité de base de chaque thread.

Notez que ce n’est pas simplement une priorité de base plus un offset:

 NORMAL_PRIORITY_CLASS + THREAD_PRIORITY_IDLE == 1 NORMAL_PRIORITY_CLASS + THREAD_PRIORITY_TIME_CRITICAL == 15 

Mais:

 REALTIME_PRIORITY_CLASS + THREAD_PRIORITY_IDLE == 16 REALTIME_PRIORITY_CLASS + THREAD_PRIORITY_TIME_CRITICAL == 31 

De plus, les threads peuvent avoir un boost temporaire (décidé et géré par Windows Scheduler). Sachez qu’un processus peut également changer sa propre classe de priorité.

En d’autres termes, toutes les tâches du pool de threads sont-elles exécutées avec la même priorité, quelle que soit la priorité du processus d’appel?

Non, la priorité du thread dépend de la priorité du processus (voir paragraphe précédent) et chaque thread du pool peut temporairement avoir une priorité différente. Notez également que la priorité du fil n’est pas affectée par la priorité du fil appelant:

 ThreadPool.QueueUserWorkItem(delegate(object s1) { Thread.CurrentThread.Priority = ThreadPriority.Highest; ThreadPool.QueueUserWorkItem(delegate(object s2) { // This code is executed with ThreadPriority.Normal Thread.CurrentThread.Priority = ThreadPriority.Lowest; // This code is executed with ThreadPriority.Lowest }); // This code is executed with ThreadPriority.Highest }); 

EDIT : les tâches .NET utilisent le pool de threads, contrairement à ce qui est écrit ci-dessus Si, par exemple, vous énumérez une collection avec Parallel.ForEach pour augmenter la priorité des threads, vous devez le faire dans votre boucle:

 Parallel.ForEach(items, item => { Thread.CurrentThread.Priority = ThreadPriority.Highest; // Your code here... }); 

Juste un avertissement: soyez prudent lorsque vous modifiez les priorités. Si, par exemple, deux threads utilisent une ressource partagée (protégée par un verrou), de nombreuses courses sont nécessaires pour acquérir ces ressources et l’une d’elles a la priorité la plus élevée. Vous risquez donc de vous retrouver avec une utilisation très importante de la CPU (en raison du comportement de rotation de Monitor.Enter ). Ceci est juste un problème, veuillez vous référer à MSDN pour plus de détails (une priorité de thread croissante peut même entraîner une dégradation des performances).

toutes les tâches du pool de threads sont-elles exécutées dans la même priorité, quelle que soit la priorité du processus d’appel?

Ils doivent. La seule chose déposée à la piscine est un délégué. Cela contient une référence à un object mais pas au Thread qui l’a déposé.

Ceux qui fonctionnent actuellement ont la même priorité. Mais il y a une queue pour celles qui ne fonctionnent pas encore – donc dans la pratique, il y a une “priorité”. De manière encore plus confuse, les priorités de threads peuvent être renforcées (et limitées) par le système d’exploitation, par exemple lorsque deux threads du pool de threads dépendent l’un de l’autre (par exemple, l’un bloque l’autre). Et bien sûr, chaque fois que quelque chose bloque sur le threadpool, vous gaspillez des ressources: D

Cela dit, vous ne devriez pas vraiment changer les priorités des threads, threadpool ou pas. Vous n’en avez pas vraiment besoin, et les priorités de threads (et de processus) ne fonctionnent pas comme vous le souhaiteriez probablement – cela ne vaut tout simplement pas la peine. Gardez tout à la normale et ignorez simplement qu’il existe une propriété Priority et vous éviterez beaucoup de problèmes inutiles 🙂

Vous trouverez de nombreuses explications intéressantes sur Internet, par exemple http://blog.codinghorror.com/thread-priorities-are-evil/ . Celles-ci sont généralement obsolètes – tout comme le concept de priorité des threads – elles ont été conçues pour des machines monocœurs à un moment où les systèmes d’exploitation n’étaient pas vraiment efficaces pour le multitâche préemptif.