In this post, we will see the concepts of
async and
await in more details.
A simple async method looks like this:
public async Task MyMethodAsync()
{
. . .
}
An
async keyword does not make a method to run asynchronously. What it does, it allows the method to use one or more
await keyword to call other asynchronous method(s). The compiler will not generate an error if we fail to provide at least one
await, it will only give a warning. We cannot use an
await in a method that does not marked with
async.
Secondly, it enables the method to return a value or exception into
Task or
Task<T> return type which will help us a lot in doing asynchronous programming.
A method that is decorated with
async will actually start running its codes synchronously like a normal method until it finds an
await keyword. Then it will see, if the method called by the
await needs to be awaited, only then an asynchronous process will happen. We will see this in more details below.
Below are two examples of using
await:
public async Task MyMethodAsync()
{
// initially this runs synchronously
. . .
// 'await' waits for an asynchronous method to complete. It enables the process to be asynchronous,
// depending on how soon the method is completing.
await RunSomethingAsync();
// the codes past 'await' will only be executed after the awaited method completes,
// however 'await' does not block the thread
. . .
}
// this second variation, shows where 'await' is used a little bit later after some other codes
public async Task MyMethodAsync()
{
// initially this runs synchronously
. . .
var result = RunSomethingAsync();
// some other codes here still run synchronously
. . .
// 'await' waits for an asynchronous method to complete. It enables the process to be asynchronous,
// depending on how soon the method is completing.
await result;
// the codes past 'await' will only be executed after the awaited method completes,
// however 'await' does not block the thread
. . .
}
This is the keyword that enables the execution process to become asynchronous. If we do not have any
await in our method, then the method will be executed synchronously even though the method is marked with
async.
The keyword calls an asynchronous method. It allows the asynchronous method to be awaited until it completes then it will continue the codes after the
await. While awaiting, it does not block the current thread but returns the control to the caller (i.e. MyMethodAsync() caller). This is when the asynchronous process is happening. The diagram in '
What Happens in an Async Method' section on
this page explains this clearly.
Only when the called asynchronous method needs to be awaited, the process becomes asynchronous. It waits for the method to complete but also allow the caller (i.e. MyMethodAsync() caller) to execute other codes. If the outer codes would encounter an
await keyword also then similar process would happen as well.
The
await keyword does not need to be put together when calling an asynchronous method, it can be called later (note in our second variation example above, the
await is not called straight away).
If the awaited method completes right away before the process above happens then all of those codes will be run in synchronous mode.
We should always use either
Task or Task<T> as the return type of our asynchronous method. The earlier is used when we do not have anything to be returned. Yes, when the method does not return anything, use
Task instead of
void (the exception will be explained below).
// below is an example of a method that returns Task<T>
public async Task<int> CalculateAsync()
{
. . .
// return an 'int' not 'Task<int>' type
return 5;
}
Task should be used because this type allows the method to be awaited using
await keyword which could lift up the process to be asynchronous. The return type enables the caller as well to know the progress when executing the method. Lastly, it encapsulates any exception that could occur inside the method to allow the exception to be handled easily.
Using
void is also possible but it should be used for event handler only. An
async void method has to use a different way to handle exception as it does not have a wrapper for the exception. It also does not provide an easy way to notify the caller when it has completed. In addition, this will be difficult to test.
Our asynchronous method will begin with the caller's thread until it finds a process that needs to be awaited by
await keyword (recall that not every asynchronous method that is called by
await needs to be awaited). When it happens, the context of the caller's thread will be captured. The awaited process will run on a new thread from thread pool. Then when the awaited task is completed, the control is returned back to the captured context which is using the original thread (caller's thread).
If the awaited task finishes before the signing up process above is completed then the rest of the codes will be run synchronously without opening a new thread (from thread pool). Thus all the codes will always run on the initial thread which is the caller's thread.
public async Task MyMethodAsync()
{
// initially this runs on the caller's thread
. . .
// since the process inside LongOperationAsync() needs to be awaited,
// the original thread is captured and signed up for continuation.
// The process is run using a new thread from thread pool
await LongOperationAsync();
// after the awaiting is complete, the control is handed back to the original thread (caller's thread)
// the codes past 'await' will be executed under original thread
. . .
}
The process to returning back the control back to the captured context has some overhead. Moreover, the original context can suffer more if it has already had a performance issue due to other processes that it handles.
Fortunately, the codes after the
await keyword can be run with a different thread unless if they really need the original context to run. For example; if the method is an ASP.NET MVC controller action method, the original context is an ASP.NET context and the codes after the
await need to do some controller related stuffs then they will need to be run under ASP.NET context as well.
To enable codes after
await to be run under a different context, we use
ConfigureAwait(continueOnCapturedContext: false).
public async Task MyMethodAsync()
{
// initially this runs on the caller's thread
. . .
// since 'ConfigureAwait(false)' is used, the process of capturing original context
// and signing up for continuation can be skipped
// the process in LongOperationAsync() is run using a new thread from thread pool
await LongOperationAsync().ConfigureAwait(continueOnCapturedContext: false);
// after the awaiting is complete, the control will continue under the newly created thread,
// the handling back process to the original context can be skipped as well
// the codes past 'await' will be executed under the newly created thread
. . .
}
Whenever possible, we should always set
ConfigureAwait(continueOnCapturedContext: false), unless if we know that we are going to need the original thread for the codes after the
await.
References and further reading:
Async and Await Post by Stephen Cleary
Best Practices in Asynchronous Programming on MSDN
Async/Await FAQ on MSDN Blogs
Asynchronous Programming with Async and Await on MSDN
