複数の待機よりも単一の「待機Task.WhenAll」を優先する必要があるのはなぜですか？

タスク完了の順序を気にせず、すべて完了する必要がある場合でもawait Task.WhenAll、複数の代わりに使用する必要がありますawaitか？たとえば、DoWork2以下の方法が推奨されますDoWork1（そしてその理由は？）：

using System;
using System.Threading.Tasks;

namespace ConsoleApp
{
    class Program
    {
        static async Task<string> DoTaskAsync(string name, int timeout)
        {
            var start = DateTime.Now;
            Console.WriteLine("Enter {0}, {1}", name, timeout);
            await Task.Delay(timeout);
            Console.WriteLine("Exit {0}, {1}", name, (DateTime.Now - start).TotalMilliseconds);
            return name;
        }

        static async Task DoWork1()
        {
            var t1 = DoTaskAsync("t1.1", 3000);
            var t2 = DoTaskAsync("t1.2", 2000);
            var t3 = DoTaskAsync("t1.3", 1000);

            await t1; await t2; await t3;

            Console.WriteLine("DoWork1 results: {0}", String.Join(", ", t1.Result, t2.Result, t3.Result));
        }

        static async Task DoWork2()
        {
            var t1 = DoTaskAsync("t2.1", 3000);
            var t2 = DoTaskAsync("t2.2", 2000);
            var t3 = DoTaskAsync("t2.3", 1000);

            await Task.WhenAll(t1, t2, t3);

            Console.WriteLine("DoWork2 results: {0}", String.Join(", ", t1.Result, t2.Result, t3.Result));
        }


        static void Main(string[] args)
        {
            Task.WhenAll(DoWork1(), DoWork2()).Wait();
        }
    }
}

はい、使用します WhenAll一度にすべてのエラーを伝播ためしてください。複数の待機があるため、前の待機の1つがスローすると、エラーが失われます。

もう1つの重要な違いは、障害（障害またはキャンセルされたタスク）がある場合でも、WhenAllすべてのタスクが完了するのを待つことです。手動で順番に待機すると、プログラムの待機したい部分が実際には早く続くため、予期しない並行処理が発生します。

また、必要なセマンティクスがコードに直接文書化されているため、コードを読みやすくなると思います。

私の理解は、Task.WhenAll複数awaitのs よりも優先する主な理由は、パフォーマンス/タスクの「チャーン」であるDoWork1ということです。このメソッドは次のようなことを行います。

• 与えられたコンテキストから始める
• コンテキストを保存する
• t1を待つ
• 元のコンテキストを復元する
• コンテキストを保存する
• t2を待つ
• 元のコンテキストを復元する
• コンテキストを保存する
• t3を待つ
• 元のコンテキストを復元する

対照的に、DoWork2これを行います：

• 与えられたコンテキストから始める
• コンテキストを保存する
• t1、t2、t3のすべてを待つ
• 元のコンテキストを復元する

これがあなたの特定のケースにとって十分に大きな取引であるかどうかは、もちろん、「コンテキスト依存」です（しゃれを許してください）。

非同期メソッドは、ステートマシンとして実装されます。ステートマシンにコンパイルされないようにメソッドを作成することは可能です。これは、ファストトラック非同期メソッドと呼ばれます。これらは次のように実装できます。

public Task DoSomethingAsync()
{
    return DoSomethingElseAsync();
}

使用Task.WhenAllする場合、呼び出し元がすべてのタスクが完了するのを待つことができることを保証しながら、このファストトラックコードを維持することが可能です。例：

public Task DoSomethingAsync()
{
    var t1 = DoTaskAsync("t2.1", 3000);
    var t2 = DoTaskAsync("t2.2", 2000);
    var t3 = DoTaskAsync("t2.3", 1000);

    return Task.WhenAll(t1, t2, t3);
}

（免責事項：この回答は、Il GriffithsのPluralsightのTPL Asyncコースから引用 /インスピレーションを得ています）

WhenAllを選択するもう1つの理由は、例外処理です。

DoWorkメソッドにtry-catchブロックがあり、それらが異なるDoTaskメソッドを呼び出しているとします。

static async Task DoWork1() // modified with try-catch
{
    try
    {
        var t1 = DoTask1Async("t1.1", 3000);
        var t2 = DoTask2Async("t1.2", 2000);
        var t3 = DoTask3Async("t1.3", 1000);

        await t1; await t2; await t3;

        Console.WriteLine("DoWork1 results: {0}", String.Join(", ", t1.Result, t2.Result, t3.Result));
    }
    catch (Exception x)
    {
        // ...
    }

}

この場合、3つのタスクすべてが例外をスローすると、最初のタスクのみがキャッチされます。それ以降の例外は失われます。つまり、t2とt3が例外をスローした場合、t2のみがキャッチされます。など。後続のタスクの例外は監視されなくなります。

WhenAllの場合と同様-タスクの一部またはすべてが失敗した場合、結果のタスクにはすべての例外が含まれます。それでも、awaitキーワードは常に最初の例外を再スローします。したがって、他の例外は依然として事実上観測されていません。これを克服する1つの方法は、タスクWhenAllの後に空の継続を追加して、待機することです。このようにして、タスクが失敗した場合、resultプロパティは完全なAggregate Exceptionをスローします。

static async Task DoWork2() //modified to catch all exceptions
{
    try
    {
        var t1 = DoTask1Async("t1.1", 3000);
        var t2 = DoTask2Async("t1.2", 2000);
        var t3 = DoTask3Async("t1.3", 1000);

        var t = Task.WhenAll(t1, t2, t3);
        await t.ContinueWith(x => { });

        Console.WriteLine("DoWork1 results: {0}", String.Join(", ", t.Result[0], t.Result[1], t.Result[2]));
    }
    catch (Exception x)
    {
        // ...
    }
}

この質問に対する他の答えは、なぜawait Task.WhenAll(t1, t2, t3);推奨されるのかという技術的な理由を提示します。この回答は、同じ結論に達しつつ、（@ usrが示唆する）柔らかな側からそれを検討することを目的としています。

await Task.WhenAll(t1, t2, t3); 意図を宣言し、アトミックであるため、より機能的なアプローチです。

を使用await t1; await t2; await t3;すると、チームメイト（またはおそらくあなたの将来の自己さえ）が個人間にコードを追加するのを妨げるものは何もありませんawaitステートメントの。確かに、それを1行に圧縮して本質的にそれを達成しましたが、それでも問題は解決しません。その上、ソースファイルが人間の目でスキャンしにくくなる可能性があるため、コードの特定の行に複数のステートメントを含めることは、チーム設定では一般的に不適切な形式です。

簡単に言うとawait Task.WhenAll(t1, t2, t3);、意図がより明確に伝えられ、コードの意味のある更新から発生する可能性のある、または単にマージがうまくいかなかったりする可能性のある特有のバグに対して脆弱ではないため、より保守しやすくなります。