2010-08-03 23 views
4

Tiré de la documentation Microsoft:Pourquoi ThreadPool a 250 threads de travail par processeur par défaut?

Par défaut, le pool de threads a 250 threads de travail par processeur disponible. Vous pouvez modifier ce paramètre à l'aide de la méthode ThreadPool.SetMaxThreads.

Il est également dit, comme il est bien connu, qu'il ya certains frais généraux:

threads ont un certain niveau de frais généraux. Par conséquent, si un ordinateur a plusieurs processeurs et que vous divisez le traitement en deux threads, vous ne verrez pas une amélioration de 100% des performances .

Sur une certaine expérience et plus de deviner, je l'aurais eu quelque chose comme 1 à 4 threads par processeur, et non ! Est-ce que quelqu'un sait pourquoi 250? Est-ce une valeur qui est censé donner meilleure performance globale, ou est-il afin d'avoir à peu près toutes les tâches que vous donnez à ce pool de threads traitées sans attendre pour d'autres tâches à terminer?

+0

Je pense préférable de demander à @serverfault – ckv

Répondre

9

La motivation n'est pas la performance. Comme vous l'avez mentionné, le fait d'avoir trop de threads peut facilement entraîner une dégradation des performances (en raison du changement de contexte, de l'écrasement du cache, des conflits, etc.).
L'idée derrière ce nombre magique est la tentative d'éviter les interblocages d'apparaître dans le code de l'utilisateur. Un développeur peut provoquer un blocage s'il met en file d'attente de nombreux éléments de travail dans un pool de threads qui attend également les autres éléments qui étaient en file d'attente dans le pool de threads. Si une situation se produit où le pool de threads a utilisé son nombre maximum de threads (ils sont tous en état d'attente), alors vous avez un deadlock.

Bien sûr, il n'y a rien de spécial avec le numéro "250", et des interblocages peuvent toujours se produire si le développeur insiste pour utiliser un tel modèle d'utilisation problématique du pool de threads. Cependant, cela devrait réduire les chances de parvenir à une impasse dans de tels scénarios.

Joe Duffy explique ce raisonnement plus en profondeur dans son article: Why the CLR 2.0 SP1's threadpool default max thread count was increased to 250/CPU.