Un ejemplo de async / await que provoca un interbloqueo

Encontré algunas de las mejores prácticas para la programación asincrónica usando c # 's async/ awaitkeywords (soy nuevo en c # 5.0).

Uno de los consejos dados fue el siguiente:

Estabilidad: conozca sus contextos de sincronización

... Algunos contextos de sincronización son no reentrantes y de un solo subproceso. Esto significa que solo se puede ejecutar una unidad de trabajo en el contexto en un momento dado. Un ejemplo de esto es el subproceso de la interfaz de usuario de Windows o el contexto de solicitud ASP.NET. En estos contextos de sincronización de un solo subproceso, es fácil bloquearse. Si genera una tarea desde un contexto de un solo subproceso, luego espera esa tarea en el contexto, su código de espera puede estar bloqueando la tarea en segundo plano.

public ActionResult ActionAsync()
{
    // DEADLOCK: this blocks on the async task
    var data = GetDataAsync().Result;

    return View(data);
}

private async Task<string> GetDataAsync()
{
    // a very simple async method
    var result = await MyWebService.GetDataAsync();
    return result.ToString();
}

Si trato de analizarlo yo mismo, el hilo principal genera uno nuevo en MyWebService.GetDataAsync();, pero como el hilo principal espera allí, espera el resultado en GetDataAsync().Result. Mientras tanto, digamos que los datos están listos. ¿Por qué el hilo principal no continúa su lógica de continuación y devuelve un resultado de cadena GetDataAsync()?

¿Puede alguien explicarme por qué hay un punto muerto en el ejemplo anterior? No tengo ni idea de cuál es el problema ...

Eche un vistazo a este ejemplo , Stephen tiene una respuesta clara para usted:

Entonces esto es lo que sucede, comenzando con el método de nivel superior ( Button1_Clickpara UI / MyController.Getpara ASP.NET):

1. Las llamadas al método de nivel superior GetJsonAsync(dentro del contexto UI / ASP.NET).

2. GetJsonAsyncinicia la solicitud REST llamando HttpClient.GetStringAsync(aún dentro del contexto).

3. GetStringAsyncdevuelve un incompleto Task, lo que indica que la solicitud REST no está completa.

4. GetJsonAsyncespera el Taskdevuelto GetStringAsync. El contexto se captura y se utilizará para seguir ejecutando el GetJsonAsyncmétodo más adelante. GetJsonAsyncdevuelve un incompleto Task, lo que indica que el GetJsonAsyncmétodo no está completo.

5. El método de nivel superior bloquea sincrónicamente el Taskdevuelto por GetJsonAsync. Esto bloquea el hilo de contexto.

6. ... Eventualmente, la solicitud REST se completará. Esto completa el Taskque fue devuelto por GetStringAsync.

7. La continuación de GetJsonAsyncahora está lista para ejecutarse y espera a que el contexto esté disponible para que pueda ejecutarse en el contexto.

8. Deadlock . El método de nivel superior está bloqueando el hilo de contexto, esperando GetJsonAsyncque se complete y GetJsonAsyncestá esperando que el contexto esté libre para que pueda completarse. Para el ejemplo de la interfaz de usuario, el "contexto" es el contexto de la interfaz de usuario; para el ejemplo de ASP.NET, el "contexto" es el contexto de solicitud de ASP.NET. Este tipo de interbloqueo puede deberse a cualquier "contexto".

Otro enlace que debería leer: ¡ Espera, interfaz de usuario y puntos muertos! ¡Oh mi!

• Hecho 1: GetDataAsync().Result;se ejecutará cuando la tarea devuelta por se GetDataAsync()complete, mientras tanto, bloquea el hilo de la interfaz de usuario
• Hecho 2: la continuación de await ( return result.ToString()) se pone en cola en el hilo de la interfaz de usuario para su ejecución
• Hecho 3: la tarea devuelta por GetDataAsync()se completará cuando se ejecute su continuación en cola
• Hecho 4: La continuación en cola nunca se ejecuta, porque el subproceso de la interfaz de usuario está bloqueado (Hecho 1)

¡Punto muerto!

El punto muerto se puede romper con las alternativas proporcionadas para evitar el Hecho 1 o el Hecho 2.

• Evite 1,4. En lugar de bloquear el subproceso de la interfaz de usuario, utilice var data = await GetDataAsync(), que permite que el subproceso de la interfaz de usuario siga ejecutándose
• Evite 2,3. Ponga en cola la continuación de la espera a un subproceso diferente que no esté bloqueado, por ejemplo var data = Task.Run(GetDataAsync).Result, use , que publicará la continuación en el contexto de sincronización de un subproceso de grupo de subprocesos. Esto permite GetDataAsync()que se complete la tarea devuelta por .

Esto se explica muy bien en un artículo de Stephen Toub , aproximadamente a la mitad de donde usa el ejemplo de DelayAsync().

Estaba jugando con este problema nuevamente en un proyecto ASP.NET MVC. Cuando desee llamar a asyncmétodos desde a PartialView, no puede realizar el PartialView async. Obtendrá una excepción si lo hace.

Puede utilizar la siguiente solución alternativa sencilla en el escenario en el que desea llamar a un asyncmétodo desde un método de sincronización:

1. Antes de la llamada, borre el SynchronizationContext
2. Haz la llamada, no habrá más puntos muertos aquí, espera a que termine
3. Restaurar el SynchronizationContext

Ejemplo:

public ActionResult DisplayUserInfo(string userName)
{
    // trick to prevent deadlocks of calling async method 
    // and waiting for on a sync UI thread.
    var syncContext = SynchronizationContext.Current;
    SynchronizationContext.SetSynchronizationContext(null);

    //  this is the async call, wait for the result (!)
    var model = _asyncService.GetUserInfo(Username).Result;

    // restore the context
    SynchronizationContext.SetSynchronizationContext(syncContext);

    return PartialView("_UserInfo", model);
}

Otro punto principal es que no debe bloquear las Tareas y usar async hasta el final para evitar interbloqueos. Entonces todo será bloqueo asíncrono, no síncrono.

public async Task<ActionResult> ActionAsync()
{

    var data = await GetDataAsync();

    return View(data);
}

private async Task<string> GetDataAsync()
{
    // a very simple async method
    var result = await MyWebService.GetDataAsync();
    return result.ToString();
}

Una solución que encontré es usar un Joinmétodo de extensión en la tarea antes de pedir el resultado.

El código se ve así:

public ActionResult ActionAsync()
{
  var task = GetDataAsync();
  task.Join();
  var data = task.Result;

  return View(data);
}

Donde el método de unión es:

public static class TaskExtensions
{
    public static void Join(this Task task)
    {
        var currentDispatcher = Dispatcher.CurrentDispatcher;
        while (!task.IsCompleted)
        {
            // Make the dispatcher allow this thread to work on other things
            currentDispatcher.Invoke(delegate { }, DispatcherPriority.SystemIdle);
        }
    }
}

No estoy lo suficientemente interesado en el dominio para ver los inconvenientes de esta solución (si corresponde)