Qual è il numero massimo di thread in Windows Server 2003?

Qualcuno sa? E una domanda più grande è cosa succede quando incontri questo massimo? È lo stesso numero con altri SO Windows come Vista, XP, ecc.?

Per prima cosa consiglierei di leggere questo: http://blogs.msdn.com/oldnewthing/archive/2007/03/01/1775759.aspx

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

Per riassumere, la limitazione è normalmente lo spazio dello stack (che deve essere in blocchi contigui) e dal momento che ogni thread consuma questo sparsi su di te rapidamente esaurito di blocchi contigui. Su macchine a 64 bit e sistemi operativi questo è molto meno un problema.

Esistono strategie di mitigazione, ma andremo così lontano (e ci affidiamo a te non usando molto stack per thread)

Come una guida approssimativa:

  • creare decine è quasi certo che funzioni
  • centinaia sono probabili su server e hardware desktop attuali ma rischiosi
  • migliaia quasi certamente falliranno.

Probabilmente non dovresti creare più di dieci (e se davvero ne hai bisogno dovresti già sapere queste informazioni)

La migliore risposta che ho sentito quando ho fatto queste domande è:

Non importa, e se trovi che è importante, devi ripensare a quello che stai facendo in modo che non abbia importanza.

Nota che dovresti esaminare attentamente il tuo progetto se sei preoccupato di raggiungere questo limite !!!!!!!!

La risposta alla tua “domanda più importante” su ciò che accade è OutOfMemoryException.

Non è esattamente una risposta diretta, ma ecco un codice per scoprire il limite. Potrebbe essere disponibile a seconda della memoria. Sarebbe interessato a vedere altri risultati OS / cpu / mem.

Sentiti libero di modificare e aggiungere la tua macchina in:

  • Windows 7, VS2008, dual core, mem 2gb: 1.465 quindi crash con 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.ToString()); } 

Per quanto comprendo l’intero modello di threading non dovrebbe essere cambiato molto da Win2K.

Non esiste un limite reale di thread di per sé, ma più un limite dei processi stack-space. Vedi una spiegazione approfondita dei limiti di threading di Raymond Chen per maggiori dettagli su questo.

Leggi i post sul blog di Raymond Chen a cui la risposta di ShuggyCoUk ha fatto riferimento.

Ma prestate particolare attenzione a questo bit:

Ma la vera domanda che si pone ogni volta che qualcuno chiede: “Qual è il numero massimo di thread che un processo può creare?” è “Perché stai creando così tanti thread che questo diventa un problema?”

Il modello “un thread per client” è ben noto per non scalare oltre una dozzina di client o giù di lì. Se hai intenzione di gestire più di così tanti client contemporaneamente, dovresti passare a un modello in cui invece di dedicare un thread a un client, devi invece allocare un object. (Un giorno rifletterò sulla dualità tra thread e oggetti.) Windows fornisce le porte di completamento I / O e un pool di thread per aiutarti a convertire da un modello basato su thread a un modello basato sul lavoro.

Se sei bloccato con un design esistente che utilizza un numero elevato di thread e deve ridimensionare, potresti anche considerare le fibre:

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

Può farti risparmiare una riprogettazione totale.

Indy l’ha considerato per Indy 10, ma non è mai successo perché le avventure di .NET hanno consumato quasi tutto il tempo che sembra.

La domanda sembra molto antica ma piace aggiungere come può essere utile anche agli altri:

Questo articolo riguarda: Spingere i limiti di Windows: processi e thread

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

La dimensione dello stack predefinita è 1 MB e lo spazio degli indirizzi in modalità utente assegnato al processo Windows sotto il SO Windows a 32 bit è di circa 2 GB. che consentono circa 2000 thread per processo (2000 * 1 MB = 2 GB). per 64 bit, praticamente, non esiste un problema simile.