È considerato accettabile non chiamare Dispose () su un oggetto Task TPL?

Voglio attivare un'attività da eseguire su un thread in background. Non voglio aspettare il completamento delle attività.

In .net 3.5 avrei fatto questo:

ThreadPool.QueueUserWorkItem(d => { DoSomething(); });

In .net 4 il TPL è il modo suggerito. Lo schema comune che ho visto consigliato è:

Task.Factory.StartNew(() => { DoSomething(); });

Tuttavia, il StartNew()metodo restituisce un Taskoggetto che implementa IDisposable. Questo sembra essere trascurato dalle persone che raccomandano questo modello. La documentazione MSDN sul Task.Dispose()metodo dice:

"Chiama sempre Dispose prima di rilasciare il tuo ultimo riferimento all'attività."

Non è possibile chiamare dispose su un'attività finché non viene completata, quindi avere il thread principale in attesa e chiamare dispose annullerebbe il punto di eseguire su un thread in background in primo luogo. Inoltre non sembra esserci alcun evento completato / finito che potrebbe essere utilizzato per la pulizia.

La pagina MSDN sulla classe Task non commenta questo aspetto e il libro "Pro C # 2010 ..." consiglia lo stesso modello e non fa alcun commento sull'eliminazione delle attività.

So che se lo lascio, il finalizzatore lo catturerà alla fine, ma questo tornerà e mi morderà quando farò molte attività di fuoco e dimentico come questa e il thread del finalizzatore viene sopraffatto?

Quindi le mie domande sono:

• È accettabile non invitare Dispose()la Taskclasse in questo caso? E se sì, perché e ci sono rischi / conseguenze?
• C'è qualche documentazione che discute questo?
• O c'è un modo appropriato per smaltire l' Taskoggetto che mi sono perso?
• O c'è un altro modo per fare fuoco e dimenticare le attività con il TPL?

C'è una discussione su questo nei forum MSDN .

Stephen Toub, un membro del team Microsoft pfx ha questo da dire:

Task.Dispose esiste a causa di Task che potenzialmente esegue il wrapping di un handle di evento utilizzato durante l'attesa del completamento dell'attività, nel caso in cui il thread in attesa debba effettivamente bloccarsi (al contrario di girare o potenzialmente eseguire l'attività su cui è in attesa). Se tutto ciò che stai facendo è usare le continuazioni, l'handle dell'evento non verrà mai assegnato
...
è probabilmente meglio fare affidamento sulla finalizzazione per occuparsi delle cose.

Aggiornamento (ottobre 2012)
Stephen Toub ha pubblicato un blog intitolato Devo smaltire le attività? che fornisce qualche dettaglio in più e spiega i miglioramenti in .Net 4.5.

In sintesi: non è necessario smaltire gli Taskoggetti il ​​99% delle volte.

Ci sono due ragioni principali per smaltire un oggetto: liberare risorse non gestite in modo tempestivo e deterministico ed evitare il costo di esecuzione del finalizzatore dell'oggetto. Nessuno di questi si applica alla Taskmaggior parte delle volte:

1. A partire da .Net 4.5, l'unica volta che a Taskalloca l'handle di attesa interno (l'unica risorsa non gestita Tasknell'oggetto) è quando si utilizza esplicitamente il IAsyncResult.AsyncWaitHandledi Task, e
2. L' Taskoggetto stesso non ha un finalizzatore; l'handle è esso stesso avvolto in un oggetto con un finalizzatore, quindi a meno che non sia allocato, non ci sono finalizzatori da eseguire.

Questo è lo stesso tipo di problema della classe Thread. Consuma 5 handle del sistema operativo ma non implementa IDisposable. Buona decisione dei progettisti originali, ovviamente ci sono pochi modi ragionevoli per chiamare il metodo Dispose (). Dovresti prima chiamare Join ().

La classe Task aggiunge un handle a questo, un evento di ripristino manuale interno. Qual è la risorsa del sistema operativo più economica che ci sia. Ovviamente, il suo metodo Dispose () può rilasciare solo quell'handle di evento, non i 5 handle consumati da Thread. Sì, non preoccuparti .

Fai attenzione che dovresti essere interessato alla proprietà IsFaulted dell'attività. È un argomento piuttosto brutto, puoi saperne di più in questo articolo di MSDN Library . Una volta affrontato correttamente questo problema, dovresti anche avere un buon posto nel tuo codice per smaltire le attività.

Mi piacerebbe vedere qualcuno soppesare la tecnica mostrata in questo post: Typesafe fire-and-forget asynchronous delegate invocation in C #

Sembra che un semplice metodo di estensione gestirà tutti i casi banali di interazione con le attività e sarà in grado di chiamare dispose su di esso.

public static void FireAndForget<T>(this Action<T> act,T arg1)
{
    var tsk = Task.Factory.StartNew( ()=> act(arg1),
                                     TaskCreationOptions.LongRunning);
    tsk.ContinueWith(cnt => cnt.Dispose());
}