Come ottenere un'attività NON da eseguire sul thread dell'interfaccia utente

Question

Il seguente codice è una semplificazione di un codice in un'applicazione reale. Il problema di seguito è che verrà eseguito un lungo lavoro nel thread dell'interfaccia utente, anziché un thread in background.

void Do() 
    { 
     Debug.Assert(this.Dispatcher.CheckAccess() == true); 
     Task.Factory.StartNew(ShortUIWork, CancellationToken.None, TaskCreationOptions.None, TaskScheduler.FromCurrentSynchronizationContext()); 
    } 

    void ShortUIWork() 
    { 
     Debug.Assert(this.Dispatcher.CheckAccess() == true); 
     Task.Factory.StartNew(LongWork, TaskCreationOptions.LongRunning); 
    } 

    void LongWork() 
    { 
     Debug.Assert(this.Dispatcher.CheckAccess() == false); 
     Thread.Sleep(1000); 
    } 

Così Do() viene chiamato normalmente dal contesto dell'interfaccia utente. E così anche ShortUIWork, come definito da TaskScheduler. Tuttavia, LongWork termina anche nel thread dell'interfaccia utente, che, ovviamente, blocca l'interfaccia utente.

Come assicurarsi che un'attività non venga eseguita nel thread dell'interfaccia utente?

Answer 1

LongRunning è solo un suggerimento per il TaskScheduler. Nel caso dello SynchronizationContextTaskScheduler (come restituito da TaskScheduler.FromCurrentSynchronizationContext()), apparentemente ignora il suggerimento.

Da un lato questo sembra controintuitivo. Dopo tutto, se l'attività è di lunga durata, è improbabile che si desideri eseguirla sul thread dell'interfaccia utente. D'altra parte, secondo MSDN:

LongRunning - Specifica che un compito sarà una lunga-running, funzionamento a grana grossa. Fornisce un suggerimento al TaskScheduler secondo cui è possibile giustificare la sottoscrizione in eccesso di .

Poiché il thread UI non è un thread pool di thread, nessun "oversubscription" (filetto piscina inedia) possono verificarsi, per cui è alquanto senso che il suggerimento non avrà alcun effetto per il SynchronizationContextTaskScheduler.

Indipendentemente da ciò, è possibile aggirare il problema passando di nuovo al task scheduler di default:

void ShortUIWork() 
{ 
    Debug.Assert(this.Dispatcher.CheckAccess() == true); 
    Task.Factory.StartNew(LongWork, CancellationToken.None, TaskCreationOptions.LongRunning, TaskScheduler.Default); 
}