The Async/Void Trap

I’ll start by saying, you should ALWAYS avoid async/void. Now, I’m sure there are edge cases, but the reality is you can get into a lot of trouble with async/void.
A good article in MSDN Magazine goes over some best practices when using async/await and asynchronous programming patterns.
As the article points out, avoid async/void. However, it also states that an exception to that rule is event handlers where the delegate returns void. Even with those event handlers, you need to be extremely careful. Here’s why–await is actually not blocking. I know if feels like it is, but remember, async/await is just syntax sugar for ContinueWith() and context management.
Let’s look at some code.
Take some method Foo() that returns void and calls an async method Bar()
async void Foo()
{
    await Bar();
}

Task Bar()
{
    return Task.Delay(10000);
}
Now, if we call Foo(), it will return immediately, and Bar() will be executed in background on another thread.
static void Main()
{
    Foo();
    Console.WriteLine("Foo Returned");
}
Not what you expected was it?
The danger? Consecutive event handlers.
One of our developers was working on a Xamarin based mobile app. Android activities have several events in the lifecyle that fire in succession–OnCreate() followed by OnResume(). There was logic in the OnCreate that was using async apis and logic in onResume that was using async apis. Because the async/void returns immediately, the Android system went ahead and called OnResume before OnCreate was actually finished. If there were no dependency order to the logic, it wouldn’t have mattered, but in our case there was.
The solution? Actually wait for the result.
void Foo()
{
    Bar().ConfigureAwait(false).GetAwaiter().GetResult();
}
ConfigureAwait(false) is used to not switch back to the original context so we don’t get a dead lock. Then we get the awaiter and get the result of the task execution. GetResult() blocks and waits for the task to complete so it can return the value of the Task.Result property.
Disclaimer: This isn’t a perfect solution either. Depending on the context, this can still dead lock.

Conslusion

Asynchronous programming is hard in a language/framework that isn’t 100% async. Scenarios like this are why Microsoft recommends “async all the way”–because as soon as you have to sprinkle some sync code in there, you can get into trouble if you’re not careful.

Comments

Post a Comment

Popular posts from this blog

Adding New Microsoft Extensions to Legacy WCF and ASMX Web Services

I was asked by several people recently: Can I use dependency injection with my legacy WCF and ASMX web services? Microsoft has some new stuff they released with core–specifically, a new configuration system, caching, and logging providers. Can I use them in my legacy WCF and ASMX web services? The answer to both is yes you can! In fact, I recommend it! To illustrate this, we’ll take a look at taking a sample application that has a WCF service and a ASMX service and we’ll: Add dependency injection using Ninject. Add the new Configuration provider from the new  Microsoft.Extensions.Configuration  packages. Add caching functionality using Microsoft’s new  Microsoft.Extensions.Caching  packages. Use the new logging providers from  Microsoft.Extensions.Logging  packages. Dependency Injection We use Ninject, but you can just as easily use AutoFac or SimpleInjector as they also have packaged integrations for WCF. You can use other containers, but may need to hand-roll your
Read more

Using NHibernate in Asp.Net Core

Starting with version 5.1, NHibernate now supports .Net Core and .Netstandard as well as the full framework. Let’s take a quick look at how to set it up in an ASP.Net Core 2.x/3.x application. Configuration As of this writing, NHibernate doesn’t support the configuration system within Asp.Net Core based on Microsoft.Extensions.Configuration. The good news is, you don’t have to use a  hibernate.cfg.xml  file or the   section in app.config. You can add the properies manually, and pull the values from Asp.Net Core’s configuration, taking advantage of all the goodies that come with it. This opens up a world of configuration deployment possibilities. var config = new Configuration (); IDictionary < string , string > properties = new Dictionary < string , string > { { "connection.connection_string" , Configuration . GetConnectionString ( "Default" ) }, { "dialect" , "NHibernate.Dialect.SQLiteDialect" },
Read more

Code Coverage for Multiple Projects in a Single Build using Dotnet Test and Coverlet

Most of the time, your solution will have more than one project and a test unit project for each of those. Azure DevOps only, as of this writing, only allows you to update a single code coverage summary. If you upload more than one, each overwrites the next and only the last one remains. To accomplish this, we can use the merge functionality in Coverlet . I use the MSBuild extension, because it is better suited for CI pipelines. In your test project XML, add the package... <PackageReference Include="coverlet.msbuild" Version="2.7.0">     <PrivateAssets>all</PrivateAssets>     <IncludeAssets>runtime; build; native; contentfiles; analyzers</IncludeAssets> </PackageReference> Then, in your dotnet test command or msbuild command, tell it to use Coverlet and to merge results. If you're using Azure DevOps, your test task looks this... (line wrapped for read ability in the article) - task: DotNetCoreCLI@2 displayName: Test i
Read more