在异步/等待中，不返回到上下文线程的后果是什么？

Question

Using async/await as shown here http://blog.stephencleary.com/2012/07/dont-block-on-async-code.html , one of the good practices is using ConfigureAwait(false) so the method return does not have to come back to the request context. What are the potential consequences of using this? Asked another way, when would this not be recommended?

Answer 1

when would this not be recommended?

Your method must return to the same context if there's code further down in the method that depends on that context. If the remainder of that method does not require a particular context, then it's a good practice to use ConfigureAwait(false) .

There are two primary examples: UI code and ASP.NET code.

UI code must run on the UI thread; this includes most UI widget access, and I extend the definition of "UI code" to include my ViewModels as well (there are some situations in WPF where you can get away with updating the UI from a background thread, but that's not true for all MVVM platforms). So, if your method ends with a textBox1.Text = "" or a myViewModel.MyObservableCollection.Add(4) , then it has to return to the UI thread before it can execute that code.

ASP.NET code must run in an ASP.NET request context; this includes any code that depends on HttpContext.Current (and many System.Web APIs implicitly assume an ASP.NET request context). So, if your method ends with HttpContext.Current.Items... , then it has to return to the ASP.NET request context before it can execute that code. (Side note: in ASP.NET vNext on .NET 4.6 and higher, the ASP.NET request context is actually going away).

In practice, what this means is that most library code should use ConfigureAwait(false) , since well-written library code does not have a dependency on a particular UI framework or System.Web . Similarly, most application code should not use ConfigureAwait(false) , since it has to update the UI / send an HTTP response.