6

Does anybody know what is the purpose of doing this?

 private async Task<bool> StoreAsync(TriviaAnswer answer) { ... }

 [ResponseType(typeof(TriviaAnswer))]
 public async Task<IHttpActionResult> Post(TriviaAnswer answer)
 {
     var isCorrect = await StoreAsync(answer);
     return Ok<bool>(isCorrect);
 }

From examining this, it is telling it to run the private method asynchronously but synchronously wait for it to end. My question is, is there any point to this? Or is this just a fancy yet futile technique? I ran into this while studying some code for Web API / MVC / SPA.

Anyway, any insights would be useful.

beautifulcoder
  • 10,832
  • 3
  • 19
  • 29
  • 1) Please show the return type of `MyMethod()` it is kind of important. And 2) Where is the syncronous wait you mention, your example code does not have one. – Scott Chamberlain Sep 08 '14 at 01:40
  • I believe the synchronous wait occurs in `await`. I'll update the code soon. – beautifulcoder Sep 08 '14 at 01:41
  • 2
    the deffination of `await` is an asynchronous wait. A syncronous wait would be `var isCorrect = StoreAsync(answer).Result;` – Scott Chamberlain Sep 08 '14 at 01:42
  • The post have some interesting misconceptions about `await` which hopefully covered in linked duplicate. If not - please provide more concrete details and I'l happily vote to reopen. – Alexei Levenkov Sep 08 '14 at 01:46
  • @AlexeiLevenkov: You're supposed to do that work *before* you close. – Robert Harvey Sep 08 '14 at 01:47
  • Thank you all! Not sure this is a duplicate since it is in the context of Web Api / ASP.NET – beautifulcoder Sep 08 '14 at 01:51
  • The decision to mark duplicate is surely too quick. That question does not even have anything specific to ASP.NET. I provided a new answer there, http://stackoverflow.com/questions/14455293/async-and-await/25716552#25716552 which you might take a look at. – Lex Li Sep 08 '14 at 02:08
  • ...in addition to what @ScottChamberlain has said, because of this, IIS can continue using the thread and process incoming requests while the async operation is taking place. – Simon Whitehead Sep 08 '14 at 02:55
  • If await was waiting for a task, why would we need syntax for it? Just call `.Wait()`. `await` does not wait. – usr Sep 11 '14 at 23:20

1 Answers1

8

Despite its name, await doesn't actually work like Thread.Join. async and await are Microsoft's implementation of coroutines, implemented using a Continuation Passing Style. Work is reordered so that processing can continue while the Task<T> is being completed. Instructions are re-arranged by the compiler to make maximum use of the asynchronous operation.

This article explains it thusly:

An await expression does not block the thread on which it is executing. Instead, it causes the compiler to sign up the rest of the async method as a continuation on the awaited task. Control then returns to the caller of the async method. When the task completes, it invokes its continuation, and execution of the async method resumes where it left off.

For some trivial code examples, await doesn't really make much sense, because there is no other work that you can do in the meantime while you are awaiting.

Robert Harvey
  • 178,213
  • 47
  • 333
  • 501
  • _there is no other work that you can do in the meantime while you are awaiting._ Can you explain this more? If multiple calls are made to `Post` the thread can begin to serve the request without having to wait for the Task to complete. – jamesSampica Sep 11 '14 at 23:28
  • Robert, I had gathered that by using async/await, you are freeing up threads so that they can go and handle other requests until the task is complete. This would improve overall performance by making your application more efficient (i.e. each thread isn't more efficient; users wouldn't notice this, but rather you're making it easier on the server). Is there any truth to this or have I missed the point? – Rowan Freeman Sep 11 '14 at 23:29
  • @RowanFreeman: I'd say that, by re-ordering the instructions that threads are executing, you're making them work more efficiently, and therefore you need fewer of them to do the same work. You have threads stalling less often because they're no longer waiting for blocking calls to complete. – Robert Harvey Sep 11 '14 at 23:36
  • @Shoe: Since your returning a Task (that is, a promise that will return a result some time in the future), and it's running on a server that handles multiple requests, I'd say you're correct. I've tweaked that part of my answer a bit. – Robert Harvey Sep 11 '14 at 23:39