espera vs Tarea. Espera - ¿Punto muerto?

No entiendo la diferencia entre Task.Waity await.

Tengo algo similar a las siguientes funciones en un servicio ASP.NET WebAPI:

public class TestController : ApiController
{
    public static async Task<string> Foo()
    {
        await Task.Delay(1).ConfigureAwait(false);
        return "";
    }

    public async static Task<string> Bar()
    {
        return await Foo();
    }

    public async static Task<string> Ros()
    {
        return await Bar();
    }

    // GET api/test
    public IEnumerable<string> Get()
    {
        Task.WaitAll(Enumerable.Range(0, 10).Select(x => Ros()).ToArray());

        return new string[] { "value1", "value2" }; // This will never execute
    }
}

¿Dónde Getquedará estancado?

Que podria causar esto? ¿Por qué esto no causa un problema cuando uso una espera de bloqueo en lugar de hacerlo await Task.Delay?

Waity await, aunque son conceptualmente similares, en realidad son completamente diferentes.

Waitse bloqueará sincrónicamente hasta que se complete la tarea. Por lo tanto, el hilo actual está literalmente bloqueado esperando que se complete la tarea. Como regla general, debe usar " asynctodo el camino hacia abajo"; es decir, no bloquee el asynccódigo. En mi blog, entro en los detalles de cómo el bloqueo en código asincrónico causa un punto muerto .

awaitesperará asincrónicamente hasta que se complete la tarea. Esto significa que el método actual está "en pausa" (se captura su estado) y el método devuelve una tarea incompleta a la persona que llama. Más tarde, cuando se awaitcompleta la expresión, el resto del método se programa como una continuación.

También mencionó un "bloque cooperativo", por el cual supongo que se refiere a una tarea que está Waitejecutando en el hilo de espera. Hay situaciones en las que esto puede suceder, pero es una optimización. Hay muchas situaciones en las que no puede suceder, como si la tarea es para otro planificador, o si ya se inició o si es una tarea sin código (como en su ejemplo de código: Waitno puede ejecutar la Delaytarea en línea porque no hay código para ello).

Puede encontrar mi async/ awaitintroducción útil.

Basado en lo que leí de diferentes fuentes:

Una awaitexpresión no bloquea el hilo en el que se está ejecutando. En cambio, hace que el compilador registre el resto del asyncmétodo como una continuación de la tarea esperada. El control luego vuelve a la persona que llama del asyncmétodo. Cuando se completa la tarea, invoca su continuación y la ejecución deasync método se reanuda donde lo dejó.

Para esperar taska que se complete un solo , puede llamar a su Task.Waitmétodo. Una llamada al Waitmétodo bloquea el hilo de llamada hasta que la instancia de clase única haya completado la ejecución. El Wait()método sin parámetros se utiliza para esperar incondicionalmente hasta que se complete una tarea. La tarea simula el trabajo llamando al Thread.Sleepmétodo para dormir durante dos segundos.

Este artículo también es una buena lectura.

Algunos hechos importantes no se dieron en otras respuestas:

La "espera asíncrona" es más compleja a nivel de CIL y, por lo tanto, cuesta memoria y tiempo de CPU.

Cualquier tarea puede cancelarse si el tiempo de espera es inaceptable.

En el caso de que "async aguarde" no tenemos un controlador para dicha tarea para cancelarlo o monitorearlo.

Usar Task es más flexible que "async aguarda".

Cualquier funcionalidad de sincronización puede ser envuelta por async.

public async Task<ActionResult> DoAsync(long id) 
{ 
    return await Task.Run(() => { return DoSync(id); } ); 
} 

No veo por qué debo vivir con la duplicación de código para el método de sincronización y asíncrono o el uso de hacks.