Cómo hacer que una tarea NO se ejecute en el subproceso UI

Question

El siguiente código es una simplificación de un código en una aplicación real. El problema a continuación es que se ejecutará un trabajo largo en el hilo de la interfaz de usuario, en lugar de un hilo de fondo.

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); 
    } 

So Do() se llama normalmente del contexto de la interfaz de usuario. Y también lo es ShortUIWork, tal como lo define TaskScheduler. Sin embargo, LongWork termina llamado también en el subproceso de interfaz de usuario, que, por supuesto, bloquea la interfaz de usuario.

¿Cómo asegurar que una tarea no se ejecute en el hilo de la interfaz de usuario?

Answer 1

LongRunning es simplemente una pista para el TaskScheduler. En el caso del SynchronizationContextTaskScheduler (según lo devuelto por TaskScheduler.FromCurrentSynchronizationContext()), aparentemente ignora la sugerencia.

Por un lado esto parece contradictorio. Después de todo, si la tarea es de larga ejecución, es poco probable que desee que se ejecute en el hilo de la interfaz de usuario. Por otra parte, de acuerdo con MSDN:

LongRunning - Especifica que la tarea será una larga ejecución, operación de grano grueso. Proporciona una pista al TaskScheduler que puede estar justificada por la sobresuscripción .

Desde el hilo de interfaz de usuario no es un hilo de rosca de la piscina, hay "exceso de suscripción" (subproceso del grupo de inanición) puede ocurrir, por lo tanto tiene sentido que la pista no tendrá ningún efecto para el SynchronizationContextTaskScheduler.

Independientemente, se puede evitar el problema al cambiar de nuevo al programador de tareas por defecto:

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