Quando non posso usare il ThreadPool in .Net?[chiuso]

Question

Quando devo non utilizzare il ThreadPool in .Net?

Sembra che l'opzione migliore è di utilizzare un ThreadPool, in questo caso, perché non è l'unica opzione?

Quali sono le vostre esperienze in tutto questo?

Answer 1

L'unico motivo per cui io non userei la ThreadPool per a buon mercato multithreading è se ho bisogno di...

1. interract con il metodo di esecuzione (ad esempio, per ucciderlo)
2. eseguire codice su un Thread STA (questo è successo a me)
3. tenere il filo vivo, dopo la mia domanda è morto (ThreadPool i thread sono thread in background)
4. nel caso in cui ho bisogno di cambiare la priorità del Thread.Non ci è possibile modificare la priorità di un thread in ThreadPool che di default è Normale.

P. S.: L'articolo di MSDN "Il Pool Di Thread Gestito" contiene una sezione intitolata, "Quando Non Usare i Thread del Pool", con una molto simile, ma leggermente più elenco completo dei possibili motivi per non usare il pool di thread.

Ci sono un sacco di motivi per cui si avrebbe bisogno di saltare l' ThreadPool, ma se non li conosci allora ThreadPool dovrebbe essere abbastanza buono per voi.

In alternativa, guardare la nuova In Parallelo Estensioni Quadro, che ha alcune cose pulite che possono soddisfare le vostre esigenze senza dover utilizzare il ThreadPool.

Answer 2

@Eric, io vado d'accordo con Dean.I thread sono costosi.Non si può assumere che il vostro programma è l'unico in esecuzione.Quando tutti sono avidi di risorse, il problema si moltiplica.

Io preferisco creare il mio thread manualmente e di controllo di loro me stesso.Mantiene il codice molto facile da capire.

Va bene quando è opportuno.Se avete bisogno di un sacco di thread di lavoro, anche se, tutto quello che hai fatto è rendere il codice più complicato.Ora è necessario scrivere il codice per gestire loro.Se hai appena usato un pool di thread, si potrebbe ottenere tutti i thread di gestione per libero.E il pool di thread forniti dal linguaggio è molto probabile che sia più robusta, più efficiente e meno buggy rispetto a ciò che il tiro per te.

Thread t = new Thread(new ThreadStart(DoSomething));  
t.Start();  
t.Join();  

Spero che normalmente sono alcune altre codice tra Start() e Join().In caso contrario, l'extra thread è inutile, e stai sprecando risorse per nessun motivo.

Le persone sono troppo paura delle risorse utilizzate dal thread.Non ho mai visto la creazione e l'avvio di un thread di prendere più di un millisecondo.Non ci sono limiti sul numero di thread che si possono creare.L'utilizzo della RAM è il minimo.Una volta che si dispone di un paio di centinaia di thread, è impegnativo diventa un problema a causa di cambi di contesto, così a quel punto si potrebbe desidera ottenere fantasia con il vostro disegno.

Un millisecondo è un lungo tempo su hardware moderno.Che 3 milioni di cicli su un 3GHz macchina.E ancora, non solo la creazione di thread.Il tuo thread di competere per la CPU con ogni altro programma di thread.Se si utilizza non-molto-troppo-numero di thread, e così fa un altro programma, poi, insieme, hai usato troppi thread.

Seriamente, non rendere la vita più complessa di quanto deve essere.Non utilizzare il pool di thread a meno che non avete bisogno di qualcosa di molto specifico che offre.

Infatti.Non rendere la vita più complesse.Se il programma ha bisogno di più thread di lavoro, non reinventare la ruota.Utilizzare il pool di thread.Ecco perché è lì.Vuoi arrotolare classe string?

Answer 3

Pool di Thread senso ogni volta che si ha il concetto di thread di lavoro.Ogni volta che si può facilmente partizione di elaborazione in piccoli lavori, ciascuno dei quali può essere elaborate in modo indipendente, i thread di lavoro (e quindi di un pool di thread) senso.

Pool di Thread non ha senso se è necessario thread che esegue completamente diversi e non correlati ad azioni che non possono essere considerati "offerte di lavoro";ad esempio, Un thread per la GUI di gestione dell'evento, un altro per l'elaborazione back-end.Pool di Thread non ha senso quando l'elaborazione costituisce una pipeline.

In pratica, se avete thread per l'avvio, l'elaborazione di un lavoro e uscire, un pool di thread è probabilmente la strada da percorrere.In caso contrario, il pool di thread non è davvero intenzione di aiutare.

Answer 4

Per litigiosi la risposta, vorrei aggiungere che è meglio non utilizzare un thread ThreadPool se è necessario per garantire che i tuoi thread di iniziare a lavorare immediatamente.Il numero massimo di thread in esecuzione di pool di thread è limitato al dominio di applicazione, in modo che il lavoro può aspettare se sono tutti impegnati.Si chiama "coda di utente di elemento di lavoro", dopo tutto.

Due eccezioni, naturalmente:

1. È possibile modificare il numero massimo di thread di pool di thread in codice, in fase di runtime, quindi non c'è niente per impedire il controllo di corrente vs numero massimo e alzando il massimo, se necessario.
2. Girando un nuovo thread viene fornito con la sua penalità di tempo - se vale la pena per voi di prendere il colpo varia a seconda delle circostanze.

Answer 5

Non sto parlando come qualcuno con un solo conoscenze teoriche qui.Scrivo e mantenere applicazioni ad alto volume che fanno pesante uso del multithreading, e io di solito non trovare il thread piscina per essere la risposta corretta.

Ah, argomento dall'autorità, ma sempre essere sullo sguardo fuori per le persone che potrebbero essere sul kernel di Windows squadra.

Nessuno di noi erano a discutere con il fatto che se si dispone di alcuni requisiti specifici quindi l' .NET ThreadPool potrebbe non essere la cosa giusta.Di cosa stiamo contestando è la banalizzazione dei costi per la macchina di creazione di un thread.

La notevole spesa di creazione di un thread a la ragion d'essere per il ThreadPool, in primo luogo.Non voglio che le mie macchine da riempire con il codice scritto da persone che sono stati male informati circa le spese di creazione di un thread, e non, per esempio, di sapere che essa provoca un metodo per essere chiamato in ogni singola DLL che è collegato al processo (alcuni dei quali saranno creati da 3 ° parti), e che può ben caldo fino a un carico di codice che non ha bisogno di essere in RAM e quasi certamente non ha bisogno di essere in L1.

La forma della gerarchia di memoria in una macchina moderna significa che 'distrae' una CPU è la peggior cosa che si riesce a fare, e tutti coloro che si preoccupa per il loro mestiere deve lavorare duro per evitare di.

Answer 6

Quando si sta andando a eseguire un'operazione che sta andando a prendere un lungo periodo di tempo, o forse un continuo thread in background.Credo che si potrebbe spingere sempre la quantità di thread disponibili in piscina, ma ci sarebbe un piccolo punto a sopportare i costi di gestione di un thread che non è mai sta per essere restituito alla piscina.

Answer 7

MSDN è un elenco di alcuni motivi qui:

http://msdn.microsoft.com/en-us/library/0ka9477y.aspx

Ci sono diversi scenari in cui è opportuno creare e gestire il tuo thread invece di usare i thread pool:

• Hai bisogno di un thread in primo piano.
• Hai bisogno di un thread per avere una particolare priorità.
• Avete le attività che causano il filo per bloccare per lunghi periodi di tempo.Il pool di thread è il numero massimo di thread, quindi un grande numero di thread bloccato pool di thread potrebbe impedire attività da di partenza.
• È necessario inserire il thread in un thread singolo appartamento.Tutti i thread ThreadPool sono in multithread appartamento.
• È necessario disporre di una stabile identità associata con il filo, o dedicare un thread a un compito.

Answer 8

Threadpool thread sono appropriate per le attività che soddisfano entrambi i seguenti criteri:

1. Il compito non è necessario spendere ogni momento significativo in attesa che accada qualcosa
2. Tutto ciò che è in attesa per la fine dell'operazione sarà probabilmente in attesa per molti compiti da finire, quindi la sua priorità non è suscettibile di influenzare di molto le cose.

Utilizzando un threadpool thread invece di creare un nuovo vi farà risparmiare un significativo ma limitato periodo di tempo.Se il tempo è significativo rispetto al tempo necessario per eseguire un compito, un threadpool compito è probabilmente appropriato.Più lungo è il tempo necessario per eseguire un compito, tuttavia, il più piccolo è il vantaggio di utilizzare il threadpool e maggiore è la probabilità che il compito di ostacolare la threadpool efficienza.

Answer 9

@Eric

@Derek, non esattamente d'accordo con lo scenario si utilizza come un esempio.Se non sai esattamente che cosa è in esecuzione sulla vostra macchina e esattamente quante totale thread, maniglie, tempo di CPU, RAM, ecc, che l'applicazione utilizzerà sotto di una certa quantità di carico, siete nei guai.

Sei l'unico target di clientela per i programmi di scrittura?Se non, si può essere certi circa la maggior parte di che.In genere non hanno idea di quando si scrive un programma, se intende eseguire in modo efficace da solo o se verrà eseguito su un server web è stato martellato da un attacco DDOS.Non è possibile sapere quanto tempo di CPU che si sta per avere.

Assumendo che il comportamento del programma cambia in base all'input, è raro anche sapere esattamente quanta memoria o CPU volta che il programma utilizzerà.Certo, si dovrebbe avere una buona idea circa il modo in cui il programma si comporterà, ma la maggior parte dei programmi non sono mai analizzato per determinare esattamente la quantità di memoria, come molti maniglie, etc.verrà utilizzato, in quanto un'analisi completa è costoso.Se non la scrittura di software real-time, il guadagno non vale la pena lo sforzo.

In generale, la pretesa di sapere esattamente come il vostro programma di comportarsi è inverosimile, e la pretesa di sapere tutto sulla macchina approcci ridicolo.

E ad essere onesti, se non si sa esattamente quale metodo si deve utilizzare:manuale thread pool di thread, delegati, e come per la sua attuazione a fare ciò che le vostre esigenze di applicazione, si è in difficoltà.

Io non sono d'accordo, ma non vedo come rilevanti.Questo sito è, in particolare, perché i programmatori non sempre hanno tutte le risposte.

Se la vostra applicazione è sufficientemente complessa da richiedere la limitazione del numero di thread che si utilizza, non si è quasi sempre andando a voler di più il controllo di ciò che il quadro ti dà?

No.Se ho bisogno di un pool di thread, io uso quello fornito, a meno che e fino a quando ho trovato che non è sufficiente.Non voglio dare per scontato il fatto che la condizione di pool di thread è insufficiente per le mie esigenze, senza la conferma che per essere il caso.

Non sto parlando come qualcuno con solo la conoscenza teorica qui.Scrivo e mantenere elevato il volume di applicazioni che fanno uso del multithreading, e io di solito non trovare il pool di thread per essere la risposta corretta.

La maggior parte della mia esperienza professionale è stata con il multithreading e la elaborazione dei programmi.Mi sono spesso necessari per ripristinare la mia soluzione.Questo non significa che il pool di thread non è utile o opportuno, in molti casi.Il pool di thread è costruito per gestire i thread di lavoro.Nei casi In cui più thread di lavoro appropriati, il pool di thread deve di solito dovrebbe essere il primo approccio.