Consider the following (based on the default MVC template), which is a simplified version of some "stuff" that happens in the background - it completes fine, and shows the expected result, 20:
public ActionResult Index()
{
var task = SlowDouble(10);
string result;
if (task.Wait(2000))
{
result = task.Result.ToString();
}
else
{
result = "timeout";
}
ViewBag.Message = result;
return View();
}
internal static Task<long> SlowDouble(long val)
{
TaskCompletionSource<long> result = new TaskCompletionSource<long>();
ThreadPool.QueueUserWorkItem(delegate
{
Thread.Sleep(50);
result.SetResult(val * 2);
});
return result.Task;
}
However, now if we add some async
into the mix:
public static async Task<long> IndirectSlowDouble(long val)
{
long result = await SlowDouble(val);
return result;
}
and change the first line in the route to:
var task = IndirectSlowDouble(10);
then it does not work; it times out instead. If we add breakpoints, the return result;
in the async
method only happens after the route has already completed - basically, it looks like the system is unwilling to use any thread to resume the async
operation until after the request has finished. Worse: if we had used .Wait()
(or accessed .Result
), then it will totally deadlock.
So: what is with that? The obvious workaround is "don't involve async
", but that is not easy when consuming libraries etc. Ultimately, there is no functional difference between SlowDouble
and IndirectSlowDouble
(although there is obvious a structural difference).
Note: the exact same thing in a console / winform / etc will work fine.
It's to do with the way the synchronization context is implemented in ASP.NET (Pre .NET 4.5). There's tons of questions about this behavior:
Task.WaitAll hanging with multiple awaitable tasks in ASP.NET
Asp.net SynchronizationContext locks HttpApplication for async continuations?
In ASP.NET 4.5, there's a new implementation of the sync context that's described in this article.
http://blogs.msdn.com/b/webdev/archive/2012/11/19/all-about-httpruntime-targetframework.aspx
When you use
.Result
there is always a possibility of deadlock because.Result
is blocking by nature. The way to avoid deadlocks is to not block on Tasks (you should useasync
andawait
all the way down). The subject is in details described here:One fix is to add
ConfigureAwait
:Another fix is to use
async
/await
throughout: