Why is writing ConfigureAwait(false) on every line with await always recommended and do I really need it?

Question

The question is not about what ConfigureAwait does. But rather why literally everywhere I see something like

As a general rule, yes. ConfigureAwait(false) should be used for every await unless the method needs its context.

I.e. they propose that I should write

await Method1().ConfigureAwait(false);
await Method2().ConfigureAwait(false);
// Do something else
// ...
await Method3().ConfigureAwait(false);
await Method4().ConfigureAwait(false);

But in such case wouldn't be clearer just resetting context in the very beginning just once like

await Task.Yield().ConfigureAwait(false);

It guarantees that the code below will be executed with no sync context, doesn't it?

I.e. I read that writing ConfigureAwait once might not work if the method returns immediately. And for me the obvious solution looks like call ConfigureAwait(false) on something that for sure doesn't return immediately, which Task.Yield is, right?

Also as I know the Task.Yield doesn't contain ConfigureAwait anymore(don't know why, as I know it used to have it before), but looking at the Task.Yield code it is pretty easy to write your own method which would do nothing more but calling the continuation with an empty sync context.

And for me it seems much much easier to read and especially to write when you write one time

await TaskUtility.ResetSyncContext();

than writing ConfigureAwait on every line.

Will that work(Task.Yield().ConfigureAwait(false) or similar custom method) or I miss something?

Answer 1

As a general rule, yes. ConfigureAwait(false) should be used for every await unless the method needs its context.

I've seen that advice often here on Stack Overflow, and it's even what Stephen Cleary (a Microsoft MVP) says in his Async and Await article:

A good rule of thumb is to use ConfigureAwait(false) unless you know you do need the context.

Stephen definitely knows his stuff, and I agree that the advice is technically accurate, but I've always thought that this is bad advice for two reasons:

1. Beginners, and
2. Maintenance risk

First, it's bad advice for beginners because synchronization context is a complex subject. If you start learning async/await by being told that "ConfigureAwait(false) should be used for every await unless the method needs its context", but you don't even know what "context" is and what it means to "need it", then you don't know when you shouldn't use it, so you end up always using it. That means you can run into bugs that will be very difficult to figure out unless you happen to learn that, yes, you did actually need that "context" thing and this magical "ConfigureAwait" thing made you lose it. You can lose hours trying to figure that out.

For applications of any kind, I believe the advice really should be the opposite: Don't use ConfigureAwait at all, unless you know what it does and you have determined that you absolutely don't need the context after that line.

However, determining you don't need the context can be either simple, or quite complex depending on what methods are called after. But even then - and this is the second reason I disagree with that advice - just because you don't need the context after that line right now, doesn't mean some code won't be added later that will use the context. You'll have to hope that whoever makes that change knows what ConfigureAwait(false) does, sees it, and removes it. Using ConfigureAwait(false) everywhere creates a maintenance risk.

This is what another Stephen, Stephen Toub (a Microsoft employee), recommends in the ConfigureAwait FAQ under the subheading "When should I use ConfigureAwait(false)?":

When writing applications, you generally want the default behavior (which is why it is the default behavior). ... This leads to the general guidance of: if you’re writing app-level code, do not use ConfigureAwait(false)

In my own application code, I don't bother trying to figure out where I can and can't use it. I just ignore that ConfigureAwait exists. Sure, there can be a performance improvement by using it where you can, but I really doubt that it will be a noticeable difference to any human, even if it is measurable by a timer. I don't believe the return on investment is positive.

The only exception to this is when you're writing libraries, as Stephen Toub points out in his article:

if you’re writing general-purpose library code, use ConfigureAwait(false)

That's for two reasons:

1. A library has no idea about the context of the application it's being used in, so it can't use the context anyway, and
2. If the person using the library decides to wait synchronously on your asynchronous library code, it could cause a deadlock that they cannot change because they can't change your code. (ideally, they shouldn't do that, but it can happen)

To address another point in your question: it's not always enough to use ConfigureAwait(false) on the first await and not the rest. Use it on every await in your library code. Stephen Toub's article under the heading "Is it ok to use ConfigureAwait(false) only on the first await in my method and not on the rest?" says, in part:

If the await task.ConfigureAwait(false) involves a task that’s already completed by the time it’s awaited (which is actually incredibly common), then the ConfigureAwait(false) will be meaningless, as the thread continues to execute code in the method after this and still in the same context that was there previously.

Edit: I finally got around to making this into an article on my site: Don’t use ConfigureAwait(false)