¿Por qué se bloquea esta acción asincrónica?

Tengo una aplicación .Net 4.5 de varios niveles que llama a un método que usa las palabras clave nuevas asyncy las awaitpalabras clave de C # que simplemente se cuelgan y no veo por qué.

En la parte inferior tengo un método asincrónico que amplía nuestra utilidad de base de datos OurDBConn(básicamente un contenedor para el subyacente DBConnectiony los DBCommandobjetos):

public static async Task<T> ExecuteAsync<T>(this OurDBConn dataSource, Func<OurDBConn, T> function)
{
    string connectionString = dataSource.ConnectionString;

    // Start the SQL and pass back to the caller until finished
    T result = await Task.Run(
        () =>
        {
            // Copy the SQL connection so that we don't get two commands running at the same time on the same open connection
            using (var ds = new OurDBConn(connectionString))
            {
                return function(ds);
            }
        });

    return result;
}

Luego tengo un método asincrónico de nivel medio que llama a esto para obtener algunos totales de ejecución lenta:

public static async Task<ResultClass> GetTotalAsync( ... )
{
    var result = await this.DBConnection.ExecuteAsync<ResultClass>(
        ds => ds.Execute("select slow running data into result"));

    return result;
}

Finalmente tengo un método de UI (una acción MVC) que se ejecuta sincrónicamente:

Task<ResultClass> asyncTask = midLevelClass.GetTotalAsync(...);

// do other stuff that takes a few seconds

ResultClass slowTotal = asyncTask.Result;

El problema es que se cuelga de esa última línea para siempre. Hace lo mismo si llamo asyncTask.Wait(). Si ejecuto el método SQL lento directamente, tarda unos 4 segundos.

El comportamiento que espero es que cuando llegue asyncTask.Result, si no está terminado, debe esperar hasta que lo esté, y una vez que lo esté, debe devolver el resultado.

Si paso con un depurador, la declaración SQL se completa y la función lambda finaliza, pero nunca se llega a la return result;línea de GetTotalAsync.

¿Alguna idea de lo que estoy haciendo mal?

¿Alguna sugerencia sobre dónde debo investigar para solucionar este problema?

¿Podría ser un punto muerto en alguna parte y, de ser así, hay alguna forma directa de encontrarlo?

Sí, eso es un callejón sin salida. Y un error común con el TPL, así que no se sienta mal.

Cuando escribe await foo, el tiempo de ejecución, de forma predeterminada, programa la continuación de la función en el mismo SynchronizationContext en el que comenzó el método. En inglés, digamos que llamó a su ExecuteAsyncdesde el hilo de la interfaz de usuario. Su consulta se ejecuta en el hilo del grupo de subprocesos (porque llamó Task.Run), pero luego espera el resultado. Esto significa que el tiempo de ejecución programará su " return result;" línea para que se ejecute de nuevo en el hilo de la interfaz de usuario, en lugar de programarla de nuevo en el grupo de hilos.

Entonces, ¿cómo funciona este punto muerto? Imagina que solo tienes este código:

var task = dataSource.ExecuteAsync(_ => 42);
var result = task.Result;

Entonces, la primera línea inicia el trabajo asincrónico. La segunda línea bloquea el hilo de la interfaz de usuario . Entonces, cuando el tiempo de ejecución quiere ejecutar la línea "return result" en el hilo de la interfaz de usuario, no puede hacerlo hasta que se Resultcomplete. Pero, por supuesto, el Resultado no se puede dar hasta que se produzca la devolución. Punto muerto.

Esto ilustra una regla clave para usar el TPL: cuando lo usa .Resulten un subproceso de IU (o algún otro contexto de sincronización elegante), debe tener cuidado de asegurarse de que nada de lo que Task depende esté programado en el subproceso de IU. O de lo contrario ocurre la maldad.

Entonces, ¿Qué haces? La opción # 1 es usar await en todas partes, pero como dijiste, esa no es una opción. La segunda opción que está disponible para usted es simplemente dejar de usar await. Puede reescribir sus dos funciones para:

public static Task<T> ExecuteAsync<T>(this OurDBConn dataSource, Func<OurDBConn, T> function)
{
    string connectionString = dataSource.ConnectionString;

    // Start the SQL and pass back to the caller until finished
    return Task.Run(
        () =>
        {
            // Copy the SQL connection so that we don't get two commands running at the same time on the same open connection
            using (var ds = new OurDBConn(connectionString))
            {
                return function(ds);
            }
        });
}

public static Task<ResultClass> GetTotalAsync( ... )
{
    return this.DBConnection.ExecuteAsync<ResultClass>(
        ds => ds.Execute("select slow running data into result"));
}

¿Cual es la diferencia? Ahora no hay espera en ningún lugar, por lo que no se programa implícitamente nada en el hilo de la interfaz de usuario. Para métodos simples como estos que tienen un solo retorno, no tiene sentido hacer un var result = await...; return resultpatrón " "; simplemente elimine el modificador asíncrono y pase el objeto de tarea directamente. Es menos sobrecarga, al menos.

La opción n. ° 3 es especificar que no desea que sus esperas se programen nuevamente en el subproceso de la interfaz de usuario, sino que solo programe en el grupo de subprocesos. Haces esto con el ConfigureAwaitmétodo, así:

public static async Task<ResultClass> GetTotalAsync( ... )
{
    var resultTask = this.DBConnection.ExecuteAsync<ResultClass>(
        ds => return ds.Execute("select slow running data into result");

    return await resultTask.ConfigureAwait(false);
}

Esperar una tarea normalmente se programaría en el subproceso de la interfaz de usuario si estás en ella; esperando el resultado de ContinueAwaitignorará el contexto en el que se encuentre, y siempre programará el threadpool. La desventaja de esto es que tienes que esparcirlo por todas partes en todas las funciones de las que depende tu .Result, porque cualquier error .ConfigureAwaitpuede ser la causa de otro punto muerto.

Este es el asyncescenario clásico de punto muerto mixto , como describo en mi blog . Jason lo describió bien: de forma predeterminada, se guarda un "contexto" en cada uno awaity se utiliza para continuar con el asyncmétodo. Este "contexto" es el actual a SynchronizationContextmenos que lo sea null, en cuyo caso es el actual TaskScheduler. Cuando el asyncmétodo intenta continuar, primero vuelve a entrar en el "contexto" capturado (en este caso, un ASP.NET SynchronizationContext). ASP.NET SynchronizationContextsolo permite un hilo en el contexto a la vez, y ya hay un hilo en el contexto: el hilo bloqueado Task.Result.

Hay dos pautas que evitarán este punto muerto:

1. Use asynctodo el camino hacia abajo. Mencionas que "no puedes" hacer esto, pero no estoy seguro de por qué no. ASP.NET MVC en .NET 4.5 ciertamente puede admitir asyncacciones, y no es un cambio difícil de realizar.
2. Utilice ConfigureAwait(continueOnCapturedContext: false)tanto como sea posible. Esto anula el comportamiento predeterminado de reanudar en el contexto capturado.

Estaba en la misma situación de punto muerto, pero en mi caso llamando a un método asíncrono desde un método de sincronización, lo que me funciona fue:

private static SiteMetadataCacheItem GetCachedItem()
{
      TenantService TS = new TenantService(); // my service datacontext
      var CachedItem = Task.Run(async ()=> 
               await TS.GetTenantDataAsync(TenantIdValue)
      ).Result; // dont deadlock anymore
}

¿Es este un buen enfoque, alguna idea?

Solo para agregar a la respuesta aceptada (no hay suficiente representante para comentar), tuve este problema al bloquear el uso task.Result, aunque todos los eventos que aparecen a awaitcontinuación ConfigureAwait(false), como en este ejemplo:

public Foo GetFooSynchronous()
{
    var foo = new Foo();
    foo.Info = GetInfoAsync.Result;  // often deadlocks in ASP.NET
    return foo;
}

private async Task<string> GetInfoAsync()
{ 
    return await ExternalLibraryStringAsync().ConfigureAwait(false);
}

El problema en realidad reside en el código de la biblioteca externa. El método de la biblioteca asincrónica intentó continuar en el contexto de sincronización de llamada, sin importar cómo configuré la espera, lo que llevó a un punto muerto.

Por lo tanto, la respuesta fue lanzar mi propia versión del código de la biblioteca externa ExternalLibraryStringAsync, para que tuviera las propiedades de continuación deseadas.

Después de mucho dolor y angustia, encontré la solución enterrada en esta publicación de blog (Ctrl-f para 'punto muerto'). Gira en torno al uso task.ContinueWith, en lugar de al desnudo task.Result.

Ejemplo de interbloqueo anterior:

public Foo GetFooSynchronous()
{
    var foo = new Foo();
    foo.Info = GetInfoAsync.Result;  // often deadlocks in ASP.NET
    return foo;
}

private async Task<string> GetInfoAsync()
{ 
    return await ExternalLibraryStringAsync().ConfigureAwait(false);
}

Evite el punto muerto como este:

public Foo GetFooSynchronous
{
    var foo = new Foo();
    GetInfoAsync()  // ContinueWith doesn't run until the task is complete
        .ContinueWith(task => foo.Info = task.Result);
    return foo;
}

private async Task<string> GetInfoAsync
{
    return await ExternalLibraryStringAsync().ConfigureAwait(false);
}

respuesta rápida: cambie esta línea

ResultClass slowTotal = asyncTask.Result;

a

ResultClass slowTotal = await asyncTask;

¿por qué? no debe usar .result para obtener el resultado de las tareas dentro de la mayoría de las aplicaciones, excepto las aplicaciones de consola, si lo hace, su programa se bloqueará cuando llegue allí

también puede probar el siguiente código si desea utilizar .Result

ResultClass slowTotal = Task.Run(async ()=>await asyncTask).Result;