Ci sono casi in cui è preferibile utilizzare un semplice oggetto Thread vecchio invece di uno dei costrutti più recenti?

Vedo molte persone nei post del blog e qui su SO che evitano o sconsigliano l'uso della Threadclasse nelle versioni recenti di C # (e intendo ovviamente 4.0+, con l'aggiunta di Task& friends). Anche prima, c'erano dibattiti sul fatto che la funzionalità di un semplice vecchio thread può essere sostituita in molti casi dalla ThreadPoolclasse.

Inoltre, altri meccanismi specializzati stanno ulteriormente rendendo la Threadclasse meno attraente, come Timers che sostituisce il brutto Thread+ Sleepcombo, mentre per le GUI abbiamo BackgroundWorker, ecc.

Tuttavia, Threadsembra rimanere un concetto molto familiare per alcune persone (me compreso), persone che, quando si confrontano con un compito che implica una sorta di esecuzione parallela, passano direttamente all'uso della buona vecchia Threadclasse. Ultimamente mi sono chiesto se è ora di modificare i miei modi.

Quindi la mia domanda è: ci sono casi in cui è necessario o utile utilizzare un semplice Threadoggetto vecchio invece di uno dei costrutti di cui sopra?

La classe Thread non può essere resa obsoleta perché ovviamente è un file dettaglio di implementazione di tutti gli altri pattern che menzioni.

Ma non è proprio la tua domanda; la tua domanda è

ci sono casi in cui è necessario o utile utilizzare un semplice oggetto Thread vecchio invece di uno dei costrutti di cui sopra?

Sicuro. Proprio in quei casi in cui uno dei costrutti di livello superiore non soddisfa le tue esigenze.

Il mio consiglio è che se ti trovi in ​​una situazione in cui gli strumenti di astrazione superiore esistenti non soddisfano le tue esigenze e desideri implementare una soluzione utilizzando i thread, dovresti identificare l'astrazione mancante di cui hai veramente bisogno e quindi implementare tale astrazione utilizzando i thread e quindi utilizzare l'astrazione .

I thread sono un elemento fondamentale per alcune cose (vale a dire parallelismo e asincronia) e quindi non dovrebbero essere portati via. Tuttavia , per la maggior parte delle persone e per la maggior parte dei casi d'uso ci sono cose più appropriate da usare che hai menzionato, come i pool di thread (che forniscono un bel modo di gestire molti piccoli lavori in parallelo senza sovraccaricare la macchina generando 2000 thread contemporaneamente),BackgroundWorker ( che racchiude eventi utili per un singolo lavoro di breve durata).

Ma solo perché in molti casi quelli sono più appropriati in quanto proteggono il programmatore dal reinventare inutilmente la ruota, facendo errori stupidi e simili, ciò non significa che la classe Thread sia obsoleta. È ancora usato dalle astrazioni sopra citate e ne avresti ancora bisogno se hai bisogno di un controllo granulare sui thread che non è coperto dalle classi più speciali.

Allo stesso modo, .NETnon vieta l'uso di array, nonostante List<T>sia più adatto per molti casi in cui le persone usano gli array. Semplicemente perché potresti ancora voler costruire cose che non sono coperte dalla libreria standard.

Taske Threadsono astrazioni diverse. Se vuoi modellare un thread, la Threadclasse è comunque la scelta più appropriata. Ad esempio, se hai bisogno di interagire con il thread corrente, non vedo tipi migliori per questo.

Tuttavia, come hai sottolineato, .NET ha aggiunto diverse astrazioni dedicate che sono preferibili Threadin molti casi.

La Threadclasse non è obsoleta, è ancora utile in circostanze speciali.

Dove lavoro abbiamo scritto un "processore in background" come parte di un sistema di gestione dei contenuti: un servizio Windows che monitora directory, indirizzi e-mail e feed RSS, e ogni volta che si presenta qualcosa di nuovo esegue un'attività su di esso, in genere per importare il dati.

I tentativi di utilizzare il pool di thread per questo non hanno funzionato: tenta di eseguire troppe cose contemporaneamente e di cestinare i dischi, quindi abbiamo implementato il nostro sistema di polling ed esecuzione utilizzando direttamente la Threadclasse.

Le nuove opzioni rendono meno frequente l' uso diretto e la gestione dei thread (costosi).

persone che, quando si confrontano con un'attività che implica una sorta di esecuzione parallela, passano direttamente all'uso della buona vecchia classe Thread.

Che è un modo molto costoso e relativamente complesso di fare cose in parallelo.

Nota che la spesa conta di più: non puoi usare un thread completo per fare un piccolo lavoro, sarebbe controproducente. Il ThreadPool combatte i costi, la classe Task le complessità (eccezioni, attesa e annullamento).

Per rispondere alla domanda " ci sono casi in cui è necessario o utile utilizzare un semplice oggetto Thread vecchio ", direi che un vecchio Thread semplice è utile (ma non necessario) quando hai un processo a lungo in esecuzione che non hai vinto " Non interagire mai con da un thread diverso.

Ad esempio, se stai scrivendo un'applicazione che si iscrive per ricevere messaggi da una sorta di coda di messaggi e la tua applicazione farà di più che elaborare quei messaggi, allora sarebbe utile usare un thread perché il thread sarà autonomo (cioè non lo stai aspettando per essere fatto) e non è di breve durata. L'uso della classe ThreadPool è più per mettere in coda un mucchio di elementi di lavoro di breve durata e consentire alla classe ThreadPool di gestire in modo efficiente l'elaborazione di ciascuno di essi quando è disponibile un nuovo thread. Le attività possono essere utilizzate dove useresti Thread direttamente, ma nello scenario sopra non penso che ti comprerebbero molto. Ti aiutano a interagire con il thread più facilmente (cosa che lo scenario precedente non fa

Probabilmente non è la risposta che ti aspettavi, ma uso Thread tutto il tempo durante la codifica con .NET Micro Framework. MF è abbastanza ridotto e non include astrazioni di livello superiore e la classe Thread è super flessibile quando è necessario ottenere l'ultimo bit di prestazioni da una CPU a basso MHz.

È possibile confrontare la classe Thread con ADO.NET. Non è lo strumento consigliato per portare a termine il lavoro, ma non è obsoleto. Altri strumenti si basano su di esso per facilitare il lavoro.

Non è sbagliato usare la classe Thread rispetto ad altre cose, specialmente se queste cose non forniscono una funzionalità di cui hai bisogno.

Non è decisamente obsoleto.

Il problema con le app multithread è che sono molto difficili da ottenere correttamente (il comportamento, l'input, l'output e anche lo stato interno spesso indeterministici sono importanti), quindi un programmatore dovrebbe spingere quanto più lavoro possibile a framework / strumenti. Estratto via. Ma il nemico mortale dell'astrazione è la performance.

Quindi la mia domanda è: ci sono casi in cui è necessario o utile utilizzare un semplice oggetto Thread vecchio invece di uno dei costrutti sopra?

Andrei con thread e blocchi solo se ci saranno seri problemi di prestazioni, obiettivi ad alte prestazioni.

Ho sempre usato la classe Thread quando ho bisogno di tenere il conto e controllare i thread che ho creato. Mi rendo conto che potrei usare il threadpool per contenere tutto il mio lavoro eccezionale, ma non ho mai trovato un buon modo per tenere traccia di quanto lavoro è attualmente in corso o qual è lo stato.

Invece, creo una raccolta e inserisco i thread al loro interno dopo averli ruotati: l'ultima cosa che un thread fa è rimuovere se stesso dalla raccolta. In questo modo, posso sempre dire quanti thread sono in esecuzione e posso usare la raccolta per chiedere a ciascuno cosa sta facendo. Se c'è un caso in cui ho bisogno di ucciderli tutti, normalmente dovresti impostare una sorta di flag "Abort" nella tua applicazione, aspettare che ogni thread se ne accorga da solo e si interrompa automaticamente - nel mio caso, io può camminare nella raccolta ed emettere un Thread.Abort a ciascuno a turno.

In tal caso, non ho trovato un modo migliore che lavorare direttamente con la classe Thread. Come ha detto Eric Lippert, le altre sono solo astrazioni di livello superiore ed è appropriato lavorare con le classi di livello inferiore quando le implementazioni di alto livello disponibili non soddisfano le tue necessità. Proprio come a volte è necessario eseguire chiamate API Win32 quando .NET non soddisfa esattamente le proprie esigenze, ci saranno sempre casi in cui la classe Thread è la scelta migliore nonostante i recenti "progressi".