Asynchronous programming is a critical aspect of modern .NET development. However, potential pitfalls could lead to challenging bugs or sub-optimal performance. Today, we will dive into a few of these common pitfalls and illustrate how to navigate around them successfully.
Understanding the Synchronization Context & ConfigureAwait
In .NET, the SynchronizationContext is essential for scheduling and executing work. This infrastructure allows you to use the Post method to schedule callbacks to execute typically within a particular thread. The context in which these callbacks run can change depending on the environment; for instance, in a UI application, callbacks run on the UI thread. In an ASP.NET application, the callbacks run on the request thread.
During an await operation, the current SynchronizationContext gets captured and subsequently used to resume the async method once the awaited task completes. For example, in a UI application, the code following the await keyword executes on the UI thread.
public async Task DoSomethingAsync()
{
await Task.Delay(1000); // Simulate some work.
// The rest of the method will run
// in the captured SynchronizationContext.
}
While this behavior is beneficial for UI applications as it enables updating the UI before and after the await, it can sometimes lead to issues such as deadlocks.
ConfigureAwait is a method you can call on a task before awaiting it. It dictates whether or not the SynchronizationContext is captured and used to resume the async method. If you use ConfigureAwait(false), the SynchronizationContext is not captured, and the method resumes on a ThreadPool thread.
public async Task DoSomethingAsync()
{
await Task.Delay(1000).ConfigureAwait(false);
// The rest of the method will run in a ThreadPool thread.
}
A common misconception is that you have to use ConfigureAwait(false) everywhere, all the time, just to be "safe". It's not necessarily "wrong" to use it that way, but in most cases, it's unnecessary when you're working with ASP.NET Core.
The reason it's unnecessary is that ASP.NET Core does not have a SynchronizationContext. When an await operation completes, the continuation (the rest of the method) is simply scheduled to run on a ThreadPool thread. This is effectively the same behavior as calling ConfigureAwait(false).
However, there can be some exceptions to this rule. If your ASP.NET Core code calls into a library that uses a SynchronizationContext (for example, a UI library or a library that interacts with specific hardware devices), or if you've added a custom SynchronizationContext to your ASP.NET Core project, then you may still want to use ConfigureAwait(false).
And even though ConfigureAwait(false) isn't required in ASP.NET Core, it's still a good habit to use it in your library code because your library could be used in other environments that do have a SynchronizationContext (like a desktop application).
My advice and a simple pattern to follow is to avoid using it all over the place in your ASP.NET Core applications. It's just making the codebase bloated for no reason, and if you decide to write a library that will be widely used in various scenarios, including desktop applications, using it is a must there.
Beware of Async Void
Async void methods are essentially "fire and forget" methods. They're async methods that don't return a task, and once initiated, you can't await their completion or catch any exceptions that they throw.
public async void DoSomethingAsync()
{
await Task.Delay(1000); // Simulate some work.
throw new Exception("Oops");
}
private void Button_Click(object sender, RoutedEventArgs e)
{
DoSomethingAsync(); // We can't catch the exception!
}
If an exception gets thrown within an async void method, it gets raised directly on the SynchronizationContext that was active when the method started. In a UI application, this could crash the application. Since you can't await an async void method, you won't know when it finishes, leading to unit testing and composition difficulties.
The recommended solution is to avoid async void methods (except for event handlers, where the event handling infrastructure handles exceptions). Instead, return a Task or Task<T> from your async methods, and use await to wait for their completion:
public async Task DoSomethingAsync()
{
await Task.Delay(1000); // Simulate some work.
throw new Exception("Oops");
}
private async void Button_Click(object sender, RoutedEventArgs e)
{
try
{
await DoSomethingAsync();
}
catch (Exception ex)
{
// Now we can handle the exception.
MessageBox.Show(ex.Message);
}
}
Exception Handling in Multiple Tasks
Managing multiple tasks running in parallel using Task.WhenAll() can be challenging, particularly regarding exception handling. If not careful, you could miss some exceptions or halt running tasks prematurely.
var tasks = new List<Task> { Task1(), Task2(), Task3() };
foreach (var task in tasks)
{
try
{
await task;
}
catch (Exception ex)
{
Console.WriteLine($"Task failed: {ex}");
}
}
In the above code, tasks are awaited sequentially. When a task throws an exception, the code catches it immediately, handles it, and proceeds to the next task. However, this code does not start processing the next task until the previous one completes. Although the tasks are initiated concurrently, they are not awaited concurrently. This setup could hinder the full utilization of concurrency if one task fails quickly while others take longer to complete.
A more efficient approach, particularly when you want to run tasks in parallel and handle exceptions individually after all tasks have been completed, would be to use Task.WhenAll():
var tasks = new List<Task> { Task1(), Task2(), Task3() };
try
{
await Task.WhenAll(tasks);
}
catch (Exception)
{
// Handle individual exceptions.
foreach (var task in tasks)
{
if (task.IsFaulted)
{
Console.WriteLine($"Task failed: {task.Exception}");
}
}
}
In this code, all tasks are awaited concurrently. If any task throws an exception, Task.WhenAll() will throw an AggregateException that includes the exceptions thrown by the tasks up to that point. The remaining tasks continue to run, and any exceptions they throw will be handled individually after completion.
Inappropriate Use of Task.Run for IO-Bound Operations
IO-bound operations, such as network requests or database calls, should use async IO APIs. Using Task.Run() for these operations leads to inefficient use of resources, as it occupies a mostly idle thread, waiting for the IO operation to complete.
// Warning: This is an anti-pattern!
string result = await Task.Run(() =>
{
using (var wc = new WebClient())
{
return wc.DownloadString("https://www.codecrafting.tips");
}
});
Instead, use async IO APIs, which free up the thread while waiting for the IO operation to finish:
var client = new HttpClient();
string result = await client.GetStringAsync("https://www.codecrafting.tips");
Forgetting to Await an Async Method
A common mistake during refactoring or code oversight is forgetting to await an async method. If you forget, the method starts running in a "fire and forget" mode, meaning you can't catch exceptions or get the result.
public async Task DoSomethingAsync()
{
await Task.Delay(1000); // Simulate some work.
Console.WriteLine("Done");
}
public void MyMethod()
{
DoSomethingAsync(); // Forgot to await!
Console.WriteLine("Finished");
}
In the above example, DoSomethingAsync() starts executing and immediately returns a task representing the operation. However, because you don't await the task, MyMethod() continue executing without waiting DoSomethingAsync() to complete. As a result, "Finished" will be printed to the console before "Done", contrary to the expected sequential logic.
The correct approach, of course, is to always await your async methods, thus ensuring they complete before moving on to the next line of code:
public async Task MyMethod()
{
await DoSomethingAsync();
Console.WriteLine("Finished");
}
Remember, the compiler usually warns you if you forget to await an async method. But note that this is a compile-time warning, not an error. It's easy to ignore it, especially if your codebase has many warnings. Always strive to keep your project free of warnings, making it easier to spot such issues.
