Await on a completed task same as task.Result?

82

I'm currently reading "Concurrency in C# Cookbook" by Stephen Cleary, and I noticed the following technique: 

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

downloadTask is a call to httpclient.GetStringAsync, and timeoutTask is executing Task.Delay.

In the event that it didn't timeout, then downloadTask is already completed. Why is necessary to do a second await instead of returning downloadTask.Result, given that the task is already completed?

julio.g

출처 c# async-await
  • There's a bit of context missing here, and unless people readily have access to the book, you're going to need to include it. What is downloadTask and timeoutTask? What do they do? - Mike Perrenoud
  • I'm not seeing an actual check for successful completion here. The task could very well be faulted, and in that case the behaviour will be different (AggregateException with Result vs first exception via ExceptionDispatchInfo with await). Discussed in more detail in Stephen Toub's "Task Exception Handling in .NET 4.5": blogs.msdn.com/b/pfxteam/archive/2011/09/28/…) - Kirill Shlenskiy
  • you should make this an answer @KirillShlenskiy - Carsten
  • @MichaelPerrenoud You're right, thanks for noticing, I'll edit the question. - julio.g

2 답변

110

There are already some good answers/comments here, but just to chime in...

There are two reasons why I prefer await over Result (or Wait). The first is that the error handling is different; await does not wrap the exception in an AggregateException. Ideally, asynchronous code should never have to deal with AggregateException at all, unless it specifically wants to.

The second reason is a little more subtle. As I describe on my blog (and in the book), Result/Wait can cause deadlocks, and can cause even more subtle deadlocks when used in an async method. So, when I'm reading through code and I see a Result or Wait, that's an immediate warning flag. The Result/Wait is only correct if you're absolutely sure that the task is already completed. Not only is this hard to see at a glance (in real-world code), but it's also more brittle to code changes.

That's not to say that Result/Wait should never be used. I follow these guidelines in my own code:

  1. Asynchronous code in an application can only use await.
  2. Asynchronous utility code (in a library) can occasionally use Result/Wait if the code really calls for it. Such usage should probably have comments.
  3. Parallel task code can use Result and Wait.

Note that (1) is by far the common case, hence my tendency to use await everywhere and treat the other cases as exceptions to the general rule.

  • We encountered the deadlock using 'result' instead of 'await' in our projects. the messed up part is having no compile error and your code becomes flaky after a while. - Ahmad Mousavi
  • @Stephen would you please explain me why "Ideally, asynchronous code should never have to deal with AggregateException at all, unless it specifically wants to" - vcRobe
  • @vcRobe Because await prevents the AggregateException wrapper. AggregateException was designed for parallel programming, not asynchronous programming. - Stephen Cleary
  • > "Wait is only correct if you're absolutely sure that the task is already completed." .... Then why is it called Wait? - Ryan The Leach
  • @RyanTheLeach: The original purpose of Wait was to join to Dynamic Task Parallelism Task instances. Using it to wait for asynchronous Task instances is dangerous. Microsoft considered introducing a new "Promise" type, but chose to use the existing Task instead; the tradeoff of reusing the existing Task type for asynchronous tasks is that you do end up with several APIs that simply shouldn't be used in asynchronous code. - Stephen Cleary
7

This makes sense if timeoutTask is a product of Task.Delay, which I believe what it is in the book.

Task.WhenAny returns Task<Task>, where the inner task is one of those you passed as arguments. It could be re-written like this:

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

In either case, because downloadTask has already completed, there's a very minor difference between return await downloadTask and return downloadTask.Result. It's in that the latter will throw AggregateException which wraps any original exception, as pointed out by @KirillShlenskiy in the comments. The former would just re-throw the original exception.

In either case, wherever you handle exceptions, you should check for AggregateException and its inner exceptions anyway, to get to the cause of the error.

Linked

Related

Latest