attendre vs Task.Wait - Deadlock?

Je ne comprends pas très bien la différence entre Task.Waitet await.

J'ai quelque chose de similaire aux fonctions suivantes dans un service 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
    }
}

Où Getsera l'impasse.

Qu'est-ce qui pourrait provoquer cela? Pourquoi cela ne pose-t-il pas un problème lorsque j'utilise une attente de blocage plutôt que await Task.Delay?

Waitet await- bien que similaires sur le plan conceptuel - sont en fait complètement différents.

Waitbloquera de façon synchrone jusqu'à la fin de la tâche. Ainsi, le thread actuel est littéralement bloqué en attendant la fin de la tâche. En règle générale, vous devez utiliser " asynctout en bas"; c'est-à-dire, ne bloquez pas le asynccode. Sur mon blog, j'entre dans les détails de la façon dont le blocage en code asynchrone provoque un blocage .

awaitattendra de manière asynchrone jusqu'à la fin de la tâche. Cela signifie que la méthode actuelle est "en pause" (son état est capturé) et la méthode renvoie une tâche incomplète à son appelant. Plus tard, une fois l' awaitexpression terminée, le reste de la méthode est planifié en tant que continuation.

Vous avez également mentionné un "bloc coopératif", par lequel je suppose que vous voulez dire qu'une tâche sur laquelle vous travaillez Waitpeut s'exécuter sur le thread en attente. Il y a des situations où cela peut arriver, mais c'est une optimisation. Il y a de nombreuses situations où cela ne peut pas se produire, comme si la tâche est pour un autre planificateur, ou si elle est déjà démarrée ou si c'est une tâche non codée (comme dans votre exemple de code: Waitne peut pas exécuter la Delaytâche en ligne car il n'y a pas de code pour ça).

Vous pouvez trouver mon async/ awaitintro utile.

Sur la base de ce que j'ai lu à partir de différentes sources:

Une awaitexpression ne bloque pas le thread sur lequel elle s'exécute. Au lieu de cela, il oblige le compilateur à inscrire le reste de la asyncméthode en tant que continuation de la tâche attendue. Le contrôle revient ensuite à l'appelant de la asyncméthode. Une fois la tâche terminée, il invoque sa poursuite et l'exécution duasync méthode reprend là où elle s'était arrêtée.

Pour attendre la fin d'un single task, vous pouvez appeler sa Task.Waitméthode. Un appel à la Waitméthode bloque le thread appelant jusqu'à ce que l'instance de classe unique ait terminé l'exécution. La Wait()méthode sans paramètre est utilisée pour attendre sans condition la fin d'une tâche. La tâche simule le travail en appelant la Thread.Sleepméthode en veille pendant deux secondes.

Cet article est également une bonne lecture.

Certains faits importants n'ont pas été mentionnés dans d'autres réponses:

"async wait" est plus complexe au niveau CIL et coûte donc de la mémoire et du temps CPU.

Toute tâche peut être annulée si le temps d'attente est inacceptable.

Dans le cas où "async wait" nous n'avons pas de gestionnaire pour une telle tâche pour l'annuler ou la surveiller.

L'utilisation de Task est plus flexible que "async wait".

Toute fonctionnalité de synchronisation peut être encapsulée par async.

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

Je ne vois pas pourquoi je dois vivre avec la méthode de synchronisation et async de duplication de code ou en utilisant des hacks.