Mon pool de threads fait juste 4 ~ 5threads. Pourquoi?

Question

J'utilise la fonction QueueUserWorkItem() pour appeler le pool de threads.
Et j'ai essayé beaucoup de travail avec. (environ 30000)
mais par le gestionnaire de tâches mon application ne fait que 4 ~ 5 thread après avoir appuyé sur le bouton de démarrage.
J'ai lu le MSDN qui a dit que le nombre par défaut de limitation de thread est d'environ 500.
pourquoi juste un peu de discussions sont faites dans mon application?
Je suis impatient d'accélérer mon application et je dois dire que ce pool de threads est celui de la raison qui ralentit mon application.

grâce

Answer 1

Il est important de comprendre le fonctionnement du planificateur de pool de threads. Il a été conçu pour affiner le nombre de threads exécutant par rapport aux capacités de votre machine. Votre machine ne peut probablement exécuter que deux threads en même temps, les processeurs dual-core sont la norme actuelle. Peut-être quatre.

Ainsi, lorsque vous jetez un tas de fils sur ses genoux, il commence par activer seulement deux fils. Le reste d'entre eux sont dans une file d'attente, attendant que les cœurs du processeur deviennent disponibles. Dès que l'un de ces deux threads se termine, il en active un autre. Deux fois par seconde, il évalue ce qui se passe avec les threads actifs qui ne se terminent pas. Il fait l'hypothèse grossière que ces threads bloquent et ne progressent donc pas et permettent à un autre thread de s'activer. Vous avez maintenant trois threads en cours d'exécution. Obtenir les 500 threads, le nombre maximum de threads par défaut, prendra 249 secondes. De toute évidence, ce comportement explique ce qu'un thread doit faire pour être exécuté en tant que thread threadpool. Cela devrait se terminer rapidement et ne pas bloquer souvent. Notez que le blocage des demandes d'E/S est traité séparément.

Si ce comportement ne vous convient pas, vous pouvez utiliser un fil régulier. Il commencera à fonctionner immédiatement et à rivaliser avec les autres threads de votre programme (et du système d'exploitation) pour le temps CPU. Créer 30 000 de ces threads n'est pas possible, il n'y a pas assez de mémoire virtuelle disponible pour cela. Un système d'exploitation 32 bits efface quelque part au sud de 2000 threads, consommant toute la mémoire virtuelle disponible.Vous pouvez obtenir environ 50 000 threads sur un système d'exploitation 64 bits avant que le fichier d'échange ne soit épuisé. Tester ces limites dans un programme de production n'est pas recommandé.

Answer 2

Le threadpool est là pour que vous puissiez éviter de créer un fil pour chaque opération asynchrone pour la raison que les discussions sont chers. Si vous voulez 30.000 threads, vous allez utiliser beaucoup de mémoire pour les piles de threads et perdre beaucoup de temps CPU à faire des changements de contexte. Maintenant, créer autant de threads serait justifié si vous aviez 30 000 cœurs de processeur ...

Answer 3

Je pense que vous avez peut-être mal compris l'utilisation du pool de threads. Générer des threads et tuer des threads implique le noyau Windows et est une opération coûteuse. Si vous avez continuellement besoin de threads pour effectuer une opération asynchrone et que vous les jetez, il effectuera de nombreux appels système. Donc le pool de threads est en fait un groupe de threads qui sont créés une fois qui, au lieu de quitter quand ils terminent leur tâche, entrent réellement dans l'attente d'un autre élément pour queueuserworkitem. Le pool de threads se syntonise ensuite en fonction du nombre de threads requis simultanément pour votre processus. Si vous souhaitez tester cela, écrivez ce code:

for(int i = 0; i < 30000; i++) 
{ 
    ThreadPool.QueueUserWorkItem(myMethod); 
} 

Vous verrez que cela va créer tout un tas de threads. Peut-être pas 30000 car certains des threads créés seront réutilisés lorsque ThreadPool commencera à fonctionner à travers vos appels de fonction.