aguardar vs Task.Wait - Deadlock?

Não entendo bem a diferença entre Task.Waite await.

Eu tenho algo semelhante às seguintes funções em um serviço 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
    }
}

Onde Getserá um impasse.

O que poderia causar isso? Por que isso não causa um problema quando eu uso uma espera de bloqueio em vez de await Task.Delay?

Waite await- embora parecidos conceitualmente - são realmente completamente diferentes.

Waitserá bloqueado de forma síncrona até que a tarefa seja concluída. Portanto, o encadeamento atual é literalmente bloqueado, aguardando a conclusão da tarefa. Como regra geral, você deve usar " asynctodo o caminho"; isto é, não bloqueie o asynccódigo. No meu blog, mostro os detalhes de como o bloqueio de código assíncrono causa um conflito .

awaitaguardará assincronamente até que a tarefa seja concluída. Isso significa que o método atual está "pausado" (seu estado é capturado) e o método retorna uma tarefa incompleta para o responsável pela chamada. Posteriormente, quando a awaitexpressão for concluída, o restante do método será agendado como uma continuação.

Você também mencionou um "bloco cooperativo", pelo qual suponho que você quer dizer que uma tarefa na qual você está Waitexecutando pode ser executada no thread em espera. Há situações em que isso pode acontecer, mas é uma otimização. Há muitas situações em que isso não pode acontecer, como se a tarefa é para outro agendador, ou se já foi iniciada ou se é uma tarefa que não é de código (como no seu exemplo de código: Waitnão é possível executar a Delaytarefa em linha porque não há código por isso).

Você pode achar minha async/ awaitintrodução útil.

Com base no que li de diferentes fontes:

Uma awaitexpressão não bloqueia o encadeamento no qual está executando. Em vez disso, faz com que o compilador inscreva o restante do asyncmétodo como uma continuação da tarefa esperada. O controle retorna ao chamador do asyncmétodo. Quando a tarefa é concluída, ela invoca sua continuação e a execução do asyncmétodo continua de onde parou.

Para aguardar taska conclusão de um único , você pode chamar seu Task.Waitmétodo. Uma chamada para o Waitmétodo bloqueia o encadeamento de chamada até que a instância de classe única conclua a execução. O Wait()método sem parâmetros é usado para esperar incondicionalmente até que uma tarefa seja concluída. A tarefa simula o trabalho chamando o Thread.Sleepmétodo para dormir por dois segundos.

Este artigo também é uma boa leitura.

Alguns fatos importantes não foram dados em outras respostas:

O "async waiting" é mais complexo no nível CIL e, portanto, custa tempo de memória e CPU.

Qualquer tarefa pode ser cancelada se o tempo de espera for inaceitável.

No caso de "async aguardar", não temos um manipulador para essa tarefa cancelá-la ou monitorá-la.

O uso do Task é mais flexível que o "assíncrono aguarda".

Qualquer funcionalidade de sincronização pode ser agrupada por assíncrona.

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

Não vejo por que devo viver com a duplicação de código para o método de sincronização e assíncrona ou usando hacks.