When I cannot use ConfigureAwait(false)?

Question

According to best practices it is recommended to use .ConfigureAwait(false) with async/await keywords if you can:

await Task.Run(RunSomethingAsync).ConfigureAwait(false);

Can you please give me an example of a situation when I cannot use .ConfigureAwait(false)?

Answer 1

You "cannot" use ConfigureAwait(false) when you actually care about the synchronization context you're in. For example, imagine the following in a GUI application:

public async void SomeButtonClick(object sender, EventArgs e)
{
    var result = await SomeAsyncOperation().ConfigureAwait(false);
    textBox.Text = result;
}

When you return from ConfigureAwait, you wont be back on the UI thread. This will cause an InvalidOperationException.

Answer 2

From the source: Asynchronous .NET Client Libraries for Your HTTP API and Awareness of async/await's Bad Effects:

When you are awaiting on a method with await keyword, compiler generates bunch of code in behalf of you. One of the purposes of this action is to handle synchronization with the UI (or main) thread. The key component of this feature is the SynchronizationContext.Current which gets the synchronization context for the current thread. SynchronizationContext.Current is populated depending on the environment you are in. The GetAwaiter method of Task looks up for SynchronizationContext.Current. If current synchronization context is not null, the continuation that gets passed to that awaiter will get posted back to that synchronization context.

When consuming a method, which uses the new asynchronous language features, in a blocking fashion, you will end up with a deadlock if you have an available SynchronizationContext. When you are consuming such methods in a blocking fashion (waiting on the Task with Wait method or taking the result directly from the Result property of the Task), you will block the main thread at the same time. When eventually the Task completes inside that method in the threadpool, it is going to invoke the continuation to post back to the main thread because SynchronizationContext.Current is available and captured. But there is a problem here: the UI thread is blocked and you have a deadlock!