With the introduction of async/await, asynchronous programming in .NET becomes a breeze. However with great power, comes great responsability.
I see a lot of programmers starting enthousiastic with the Task Parallel Library and the async/await syntax but a few days later, they start to report strange bugs and issues with their code(or even worse the end-user start to report this).
Almost all the time it is because developers didn’t fully understand what’s going on behind the scenes and when we dig into the code, there is almost all the time the following code(or similar):
var httpClient = new HttpClient();var t = httpClient.GetAsync("http://stackoverflow.com", HttpCompletionOption.ResponseHeadersRead);
return t.ContinueWith(t1 => t1.Result.Content.Headers.ToString());
If you use the code above in a Console application, it should not be a problem. However if you try to do the same thing inside an ASP.NET(MVC) application you’re into trouble. Why? What makes this code different in ASP.NET vs a Console application. The answer is the SynchronizationContext. In ASP.NET, only one thread can handle a request at a time. You can do some parallel processing, but only one thread would have the request context. This is managed for you by the ASP.NET SynchronizationContext.
The moment a task attempts to resume within the ASP.NET request context when there is already a thread in that context, the thread will block and you’ll end in a deadlock situation. In the example above, the current thread will be blocked until the t1.Result is available. But t1 is waiting for the result of task t which will not be able to resume as the current thread is blocked.
How can we fix this?
Easiest solution is to correctly use the async/await syntax here and avoid the usage of the Task api’s:
var httpClient = new HttpClient();var result = await httpClient.GetAsync("http://stackoverflow.com", HttpCompletionOption.ResponseHeadersRead);
return result.Content.Headers.ToString();
Some useful links: