.ConfigureAwait(false)

[aspnet]

.ConfigureAwait(false)

[Tratcher]

Why should we? It's not a cure-all, it's a tool for addressing a specific problem that we have not needed thus far.

[MaximRouiller]

Where? The code base is more than 10 lines of codes.

[letrec]

Almost every await lacks it with very few exceptions.

[MaximRouiller]

My understanding of Awaitable and ConfigureAwait is a bit far but I'll trust @Tratcher on this.

If there is a performance problem, it's always possible to run a benchmark and prove that a certain piece of code runs better with ConfigureAwait(false).

[MaximRouiller]

Nice SO thread that also talk about it that I found helpful:

http://stackoverflow.com/a/26681648/24975

[letrec]

Actually it is quite the opposite - every await should have it unless the caller needs marshalling to the original context. Please cosider advise 6 from here https://blogs.msdn.microsoft.com/lucian/2013/11/22/talk-async-best-practices/.

[MaximRouiller]

6. Libraries should consider Task.ConfigureAwait(false). There’s another micro-optimization you can use to reduce your methods’ impact on the UI thread. Consider this if your library routine might be called from the UI thread, and has chatty awaits inside it. This technique is used throughout the .NET Framework because it also avoids deadlock in certain poor-practice user code.

I'm wary of micro-optimization and the mention of the UI thread. Is there such a thing as UI thread in Katana? I haven't contributed to this project yet but the fact that there is no bug opened for this means that it was probably already evaluated and rejected.

[Tratcher]

Indeed, we do not performance micro-optimizations unless something shows up in a performance profile. Feel free to do some profiling and let us know if you see any hot spots.

Closing this issue pending actionable data.

[vrudakovskiy]

Hi,

Agree with @letrec, there should be .ConfigureAwait(false) in the code. A few articles below may help to shed the light on ConfigureAwait and SynchronizationContext.

1. https://particular.net/blog/async-await-tips-and-tricks
2. https://msdn.microsoft.com/magazine/gg598924.aspx

ConfigureAwait

Microsoft's async/await best practices state that you should use ConfigureAwait(false) almost anytime you await something. This way, the TaskScheduler knows that it can use any available thread when the method resumes after the await. The only exception to the rule is when execution must continue on a specific thread, such as the UI thread in a client application.

When you use ConfigureAwait in your code, it often looks something like this, with the .ConfigureAwait(false) call tacked on to the end of the method that returns a Task:

public async Task AlreadyAsyncMethod()
{
   await DoSomethingAsync().ConfigureAwait(false);
}

The reason ConfigureAwait is used here is to enable tasks to continue on any available thread. For more information on why this is important, check out the article Context Matters. Suffice it to say, for library code that doesn't care which thread it executes on, you should use ConfigureAwait(false) every time you use await. Eventually, you will find that adding ConfigureAwait all over the place becomes tiresome and is easy to forget.
There are two ways you can deal with this. You can use a Roslyn-based tool to make sure you never forget to add ConfigureAwait, or you can use IL weaving so you don't have to type it manually at all. Either way, you'll come out ahead.

[letrec]

https://channel9.msdn.com/Series/Three-Essential-Tips-for-Async/Async-library-methods-should-consider-using-Task-ConfigureAwait-false-

[MaximRouiller]

https://msdn.microsoft.com/en-us/magazine/jj991977.aspx

That article mention that ConfigureAwait(false) is to be used extensively in GUI but ASP.NET does not have a UI thread per se. So it's invalid.

Aside from performance, ConfigureAwait has another important aspect: It can avoid deadlocks.

Deadlocks will only happen if you cross async code and sync code (eg. Task.Wait(...)) kind of way. If you do it properly, you don't have 2 threads waiting on each other through the SynchronizationContext.

This technique is particularly useful if you need to gradually convert an application from synchronous to asynchronous.

Again... not really meaningful.

You should not use ConfigureAwait when you have code after the await in the method that needs the context. For GUI apps, this includes any code that manipulates GUI elements, writes data-bound properties or depends on a GUI-specific type such as Dispatcher/CoreDispatcher. For ASP.NET apps, this includes any code that uses HttpContext.Current or builds an ASP.NET response, including return statements in controller actions.

I do think that this is for ASP.NET proper. Not the OWIN stack. @Tratcher could probably explain to us why it doesn't matter. My gut feeling is that there is no more use of global states stored in static and everything.

To summarize this third guideline, you should use Configure­Await when possible. Context-free code has better performance for GUI applications and is a useful technique for avoiding deadlocks when working with a partially async codebase. The exceptions to this guideline are methods that require the context.

This is the only recommendation to explicitly use it everywhere. But that article is from 2011.

I would recommend reading about ASP.NET Core SynchronizationContext.