Back to List

Async, Await, and ConfigureAwait – Oh My!

Dan Lorenz Dan Lorenz  |  
Dec 11, 2018
 
In .NET Framework 4.5, async/await keywords were added to the language to make async programming easier to work with. In order to maximize device resources and not block UI, you should really try to use asynchronous programming wherever you can. While async/await has made this much easier than before, there are a few gotchas that you may not know about.
 

New Keywords

Microsoft added async and await keywords into the .NET framework. In order to use them, however, the return type of the method should be of type Task. (There is one exception that we’ll discuss later.) In order to use the await keyword, you must have async in the method definition. If you put async in the method definition, you should have an await somewhere in the body, and you’ll normally get a warning about it from Visual Studio if you are missing one.
 
Here is an example of what it would look like in code:

 

        public async Task ExecuteAsync(UpdateCarCommand request, CancellationToken token = default)

        {

            using (var context = _contextFactory.Create())

            {

                var entity = context.Cars.FirstOrDefault(a => a.Id == request.Id);

 

                // Mapping logic

 

                await context.SaveChangesAsync(token);

            }

        }

 

If you wanted to return something from an async method, you would use the generic form of Task. It would look something like this (if you wanted to return the number of affected rows):

 

        public async Task<int> ExecuteAsync(UpdateCarCommand request, CancellationToken token = default)

        {

            using (var context = _contextFactory.Create())

            {

                var entity = context.Cars.FirstOrDefault(a => a.Id == request.Id);

 

                // Mapping logic

 

                return await context.SaveChangesAsync(token);

            }

        }

 

What does it buy us?

While using this looks simple enough, how does it help? Ultimately, all this is doing is letting other requests use the current thread while we are waiting for a result back from the database (in this case). Any time you make a request to an external source like a database, disk, internet, etc. that could take a while to run, we can use async/await to let other requests use this thread. That way, we don’t have idle “workers” (threads) sitting around waiting for something else to get done. It would be like going to a fast food place where, after you order your food, no one else can order anything until you have your food. With async/await, other people can put in their order after you, and multiple orders can be worked on at the same time.
 

What it doesn’t do

One thing to be careful of here is that async/await is NOT parallel/multi-core programming. When you use async/await, you are only working with that single thread and letting something else use it. The code acts like it is “synchronous” because you can continue the code in the same method after an await. Thus, if you have four awaits in a single method, you would have to wait for each to finish before calling the next one. Thus, you’d have to spawn new threads with the Task Library, or whatever you like, to make them run in parallel. However, you could also make each of those threads use async/await so they aren’t blocking resources, too!
 

What does .ConfigureAwait(false) do?

By default, when you use async/await, it will resume on the original thread that started the request. However, if another long-running process currently has taken over that thread, you will be stuck waiting for it to complete. To avoid this issue, you can use a method called ConfigureAwait with a false parameter. When you do, this tells the Task that it can resume itself on any thread that is available instead of waiting for the thread that originally created it. This will speed up responses and avoid many deadlocks.

However, there is a small loss here. When you resume on another thread, the thread synchronization context is lost. The biggest loss here is that you would lose any Culture or Language settings, along with things like HttpContext.Current from the original thread, though this is no longer a problem in .NET Core. Thus, if you don’t need translations or access to any HttpContext type settings, you are safe to make this call. NOTE: If you need language/culture, you can always store the current values before an await and then re-apply it after the await on the new thread.
 
Here is an example of what ConfigureAwait(false) would look like:

 

        public async Task<int> ExecuteAsync(UpdateCarCommand request, CancellationToken token = default)

        {

            using (var context = _contextFactory.Create())

            {

                var entity = context.Cars.FirstOrDefault(a => a.Id == request.Id);

 

                // Mapping logic

 

                return await context.SaveChangesAsync(token).CongifureAwait(false);

            }

        }

 

Caveats

Synchronous -> Asynchronous

There are a few things you need to keep track of if you are going to use async/await. The biggest issue you might run into has to deal with synchronous methods calling asynchronous methods. If you are starting a new project, you can normally put async/await through the entire chain of methods from top to bottom with little effort. However, if you are synchronous at the top and must call an async library, things can get a little dicey. You could end up with deadlocks all over the place if you aren’t careful.

If you have a synchronous method call an async method, you MUST use .ConfigureAwait(false). If you don’t, you will have an instant deadlock. What happens is that the main thread will call the async method, and you end up blocking this thread until that async method is complete. However, once that async method is complete, it must wait for the original caller to finish before it can resume. They are both waiting for each other to complete and never will. By using ConfigureAwait(false) on the call, the async method will be able to finish itself on another thread and alert the original thread that it is finished. The best way to make this call (so it throws the original exception directly) looks like this:

 

[HttpPut]

public IActionResult Put([FromBody]UpdateCommand command) =>

    _responseMediator.ExecuteAsync(command).ConfigureAwait(false).GetAwaiter().GetResult();

 

.NET Standard with ConfigureAwait(false)

In .NET Core, Microsoft did away with the SynchronizationContext that caused us to need ConfigureAwait(false) everywhere. Thus your ASP.NET Core app technically doesn’t need any ConfigureAwait(false) logic in them because it's redundant. However, if you have a library that is using .NET Standard, then it is highly recommended that you still use .ConfigureAwait(false). In .NET Core, this will effectively do nothing. But if someone with .NET Framework ends up using this library and calls it synchronously, they will be in big trouble.
 

ConfigureAwait(false) all the way down

If there is a possibility that a synchronous call could call your asynchronous method, you end up being forced to put .ConfigureAwait(false) on every async call through the entire call stack! If you don’t, you’ll end up with another deadlock. The problem here is that each async/await is local to the current method that invoked it. Thus, each async/await through the chain could end up resuming on different threads. If a synchronous call goes all the way down and encounters a single Task without ConfigureAwait(false) on it, then this task is going to attempt to wait for that top, original thread to complete before it can resume. While this ends up tedious and annoying, it is critical that you don’t miss any of these calls.
 

Overhead

While async/await can greatly increase the number of requests your application can work on at once, there is a cost to using it. Each async/await call will end up creating a small state machine to keep track of everything. While small, this overhead can cause slowdowns if you abuse async/await. If you are doing strictly CPU computations, it is better to avoid using async/await since the CPU is not actually waiting for anything to return. Thus, it only makes it take longer to complete. Only when your thread could be actively waiting on something external to the application should you await it.
 

Async Void

While almost all your async/await methods should return a Task of some sort, there is one exception to this rule: sometimes, you can use async void. However, when you use this, the caller will not actually wait for that task to complete before resuming itself. It is effectively a fire-and-forget kind of thing. There are two cases where you’d want to use this. 
 
The first case is being an event handler, like a button click in WPF or WinForms. By default, an event handler’s definition must be void. If you put a Task on there, the program won’t compile, and an event returning something would feel weird. If that button is calling something async, then you must do async void for it to work properly. Luckily, this is what we want since this style won’t block the UI. 
 
The second one involves firing something off that you don’t mind waiting for to get the results. The most common example would be logging an information message, or something where you’d like to log something, but don’t want to wait for it to finish and don’t care if it completes or not. 
 
For both cases, however, there are a couple disadvantages. The first is that the calling method can’t try/catch any exceptions from the call. It will end up going to the AppDomain UnhandledException event. Though, if you put a try catch inside the actual async void method, you can effectively prevent this from happening. Another problem is that the caller will never know when it finishes since it doesn’t return anything. Thus, if you care when something completes, you really need to return a Task instead.
 

Conclusion

Hopefully you’ve learned more about the new, cool async/await feature and how to use it effectively!
 
.Net Programming

 

Love our Blogs?

Sign up to get notified of new Skyline posts.

 


Related Content


Spring 2019 Kentico User Group
Apr 17, 2019
Location: Waukesha County Technical College - Pewaukee Campus - 800 Main Street, Pewaukee, Wisconsin 53072 - Building: Q, Room: Q361
Blog Article
Using Hooks to Reactify a Plain JavaScript Library: A Walkthrough
Andrew PetersenAndrew Petersen  |  
Aug 06, 2019
React Hooks make it really easy to wrap a vanilla JavaScript library with a React component so you can easily reuse it throughout your app and stay in "React Mode".In this walkthrough I'll be focusing on a single library, Shave.js, but the techniques and ideas should be applicable...
Blog Article
How to Create a Readable and Useful Bug Report
Blayne RoselleBlayne Roselle  |  
Jun 25, 2019
Creating a bug that is both readable and provides enough detail is a must-have skill for a Quality Assurance Analyst. Not only will it help when it comes time to retest, but it also provides credibility with your development team. In the content below, I will share the best practices for creating...
Blog Article
Azure Tips & Tricks: Application Insights Snapshot Debugger
Todd TaylorTodd Taylor  |  
May 21, 2019
A painful memory that is burned into my developer-brain is a production support issue for a .NET web API that I wrote years ago. I worked for a large retailer at the time, and the bug was preventing electronic pricing signs from displaying the most up-to-date price for hundreds of products at...
Blog Article
Thinking Outside the Application Development Box with Unity
Jeff WeberJeff Weber  |  
May 14, 2019
Do you or your company have an idea for an application that sits a little outside your comfort zone? Does your idea possibly require game-like graphics, Augmented Reality, Virtual Reality or similar technology? If so, Unity might be worth a look.   I’ve been using Unity in my spare...