A brief explanation of Async / Await in .Net 4.5

Question

How do asynchronous tasks (Async / Await) work in .Net 4.5?

Code example:

private async Task<bool> TestFunction() { var x = await DoesSomethingExists(); var y = await DoesSomethingElseExists(); return y; } 

Does the second await statement await immediately or after the first await returns?

Answer 1

await pauses the method until the operation completes. Thus, the second await will be executed after the first await returns.

See async / await intro or official FAQs for more information.

Answer 2

It is executed after returning the first wait. If this thing bothers you, try playing around with breakpoints - they are fully supported by the new asynchronization pattern.

Imagine what it would look like:

 var x = await GetSomeObjectInstance(); var y = await GetSomeObjectInstance2(x); 

A NullReferenceException would probably be thrown somewhere, so the first wait should return first. Otherwise, x will be null / undefined or something else.

Answer 3

Method calls will still occur sequentially, like "regular", not expected method calls. The purpose of the wait is that it will return the current thread to the thread pool, while the expected operation will run away and do something.

This is especially useful in high-performance environments, such as a web server, where a given request is processed in a given thread from a common thread pool. If we do not expect this, then the given thread processing the request (and all its resources) remains "in use" until the db / service call ends. This may take several seconds or more, especially for external service calls.

Now on sites with low traffic this is not a problem, but on sites with high traffic the cost of all these request flows simply sits, doing nothing, is in the “in use” state, waiting for other processes such as db / service calls to return may be burden of resources.

We better let the thread go back to the work pool so that it can do other useful work for another request.

As soon as the db / service call completes, we can interrupt the thread pool and ask the thread to continue processing this request from where it was stopped. At this point, the request state is reset and the method call continues.

Thus, based on the request, when they wait, the request will still take the same amount of time from the point of view of users ... plus a tiny smidge is more for the switching overhead.

But collectively, for all requests for all users, everything may seem more effective for all users, since the web server (in this case) works more efficiently with better use of resources. those. it either does not have to queue requests waiting for free threads to process requests because waiting returns them, or, alternatively, we do not need to buy more equipment because we use the same amount of hardware more efficiently so Get higher throughputs.

There is the cost of switching for this, although, despite what you see in the default templates, and in many documents, you should not just blindly use them for each individual call. It is just a tool and, like all tools, it has its place. If the cost of switching is not less than the cost of simply completing your calls synchronously, then you should not use waiting.