task.Resultと同じ完了したタスクを待ちます。

私は現在、Stephen Clearyの「C＃クックブックの並行性」を読んでおり、次のテクニックに気づきました。

var completedTask = await Task.WhenAny(downloadTask, timeoutTask);  
if (completedTask == timeoutTask)  
  return null;  
return await downloadTask;  

downloadTaskへの呼び出しでhttpclient.GetStringAsync、timeoutTask実行中Task.Delayです。

タイムアウトしなかった場合downloadTaskは、すでに完了しています。downloadTask.Resultタスクがすでに完了している場合、を返すのではなく、2回目の待機を行う必要があるのはなぜですか？

ここにはすでにいくつかの良い答え/コメントがありますが、ただチャイムするために...

私awaitがResult（またはWait）よりも好む理由は2つあります。1つ目は、エラー処理が異なることです。await例外をでラップしませんAggregateException。理想的には、非同期コードが対処する必要はありませんAggregateException、それは特にない限り、まったく望んでいるに。

2番目の理由は、もう少し微妙です。私は私のブログで説明したよう（と本の中で）、Result/ Waitデッドロックを引き起こす可能性があり、かつで使用する場合でも、より微妙なデッドロックを引き起こす可能性がありますasync方法。したがって、コードを読んでいて、Resultまたはが表示されている場合Wait、それは即時警告フラグです。Result/ Waitあなたがいる場合にのみ正しい絶対確実タスクがすでに完了していること。これは一目で（実際のコードでは）見づらいだけでなく、コードの変更がより脆弱になります。

それはそれと言うことはありませんResult/がWaitなければならない決して使用しないこと。私は自分のコードでこれらのガイドラインに従います：

1. アプリケーションの非同期コードで使用できるのはだけawaitです。
2. （ライブラリー内の）非同期ユーティリティー・コードは、コードが実際にそれを必要とする場合、時々Result/を使用できますWait。そのような使用法にはおそらくコメントが必要です。
3. 並列タスクコードはResultおよびを使用できますWait。

（1）ははるかに一般的なケースであるため、awaitどこでも使用し、他のケースを一般規則の例外として扱う傾向があることに注意してください。

これtimeoutTaskがの製品である場合、これは理にかなっていTask.Delayます。本でそれが何であるかを私は信じています。

Task.WhenAny戻りTask<Task>インナータスクは、あなたが引数として渡されたものの一つであり、。次のように書き直すことができます。

Task<Task> anyTask = Task.WhenAny(downloadTask, timeoutTask);
await anyTask;
if (anyTask.Result == timeoutTask)  
  return null;  
return downloadTask.Result; 

どちらの場合も、downloadTaskはすでに完了しているため、との間には非常に小さな違いがreturn await downloadTaskありreturn downloadTask.Resultます。AggregateExceptionコメントで@KirillShlenskiyが指摘しているように、後者は元の例外をラップするものをスローします。前者は元の例外を再スローするだけです。

どちらの場合でも、例外を処理する場合は常にAggregateException、エラーの原因を特定するために、その内部例外を確認する必要があります。