Quel est le nombre maximal de threads dans Windows Server 2003?

Tout d’abord, je vous conseille de lire ceci: http://blogs.msdn.com/oldnewthing/archive/2007/03/01/1775759.aspx

puis http://blogs.msdn.com/oldnewthing/archive/2005/07/29/444912.aspx

Pour résumer, la limitation est normalement l’espace de la stack (qui doit se trouver dans des blocs contigus) et comme chaque thread consum ce fragment dispersé, vous êtes rapidement à court de blocs contigus. Sur les machines 64 bits et les systèmes d’exploitation, cela pose beaucoup moins de problèmes.

Des stratégies d’atténuation existent mais n’iront que si loin (et vous ne comptez pas beaucoup de stack par fil)

A titre indicatif:

• créer des dizaines est presque certain de fonctionner
• des centaines est probable sur le serveur actuel et le matériel de bureau, mais risqué
• des milliers de personnes vont presque certainement échouer.

Vous ne devriez probablement pas avoir besoin de créer plus de dix (et si vous en avez vraiment besoin, vous devriez déjà connaître cette information)

La meilleure réponse que j’ai entendue en posant de telles questions est la suivante:

Ce n’est pas grave, et si vous trouvez que cela a de l’importance, vous devez repenser ce que vous faites pour que cela n’ait pas d’importance.

Notez que vous devez examiner votre conception de près si vous êtes préoccupé par le fait de vous heurter à cette limite !!!!!!!!

La réponse à votre “question plus importante” de ce qui se passe est OutOfMemoryException.

Pas exactement une réponse directe, mais voici un code pour trouver la limite. Cela pourrait être dépendant de la mémoire disponible cependant. Serait intéressé à voir d’autres résultats OS / cpu / mem.

N’hésitez pas à éditer et append votre machine dans:

• Windows 7, VS2008, dual core, 2 Go de mémoire: 1 465, puis crash avec OutOfMemoryException

  int i = 0; try { while (true) { new Thread(new ThreadStart(() => Thread.Sleep(int.MaxValue))).Start(); i++; } } catch (Exception ex) { Console.WriteLine(i); Console.WriteLine(ex.ToSsortingng()); } 

Si je comprends bien le modèle de threading complet, il ne devrait pas avoir beaucoup changé depuis Win2K.

Il n’y a pas de limite réelle des threads en soi, mais plutôt une limite de l’espace de stack des processus. Voir une explication détaillée des limites de filetage de Raymond Chen pour plus de détails à ce sujet.

Lisez les articles du blog de Raymond Chen que la réponse de ShuggyCoUk a indiqués.

Mais faites particulièrement attention à ce bit:

Mais la vraie question qui se pose chaque fois que quelqu’un demande: “Quel est le nombre maximum de threads qu’un processus peut créer?” est “Pourquoi créez-vous tellement de threads que cela devient même un problème?”

Le modèle “un thread par client” est bien connu pour ne pas dépasser une dizaine de clients. Si vous devez gérer plus de nombreux clients simultanément, vous devez passer à un modèle où, au lieu de dédier un thread à un client, vous allouez un object à la place. (Un jour, je m’interrogerai sur la dualité entre les threads et les objects.) Windows fournit des ports d’achèvement d’E / S et un pool de threads pour vous aider à convertir un modèle basé sur un thread vers un modèle basé sur des éléments de travail.

Si vous êtes coincé avec une conception existante qui utilise un grand nombre de threads et doit évoluer, vous pouvez également considérer les fibres:

http://msdn.microsoft.com/en-us/library/ms682661%28v=vs.85%29.aspx

Cela peut vous faire économiser une refonte totale.

Indy l’a considéré pour Indy 10, mais cela n’est jamais arrivé parce que les aventures .NET ont consommé la plupart du temps, semble-t-il.

La question semble très ancienne mais aime append comme peut être utile à d’autres aussi:

Cet article concerne: Repousser les limites de Windows: processus et threads

http://blogs.technet.com/b/markrussinovich/archive/2009/07/08/3261309.aspx

La taille de stack par défaut est de 1 Mo et l’espace d’adressage en mode utilisateur atsortingbué au processus Windows sous Windows OS 32 bits est d’environ 2 Go. qui permettent environ 2000 threads par processus (2000 * 1MB = 2 Go). pour 64 bit, pratiquement, il n’y a pas un tel problème.