async keyword
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.
await Keyword
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.
Task and Task<T>
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.
Execution Thread
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
No comments:
Post a Comment