Why you should use ConfigureAwait(false) in library code

Await task uses the sync context

1. it captures the current syncContext before awaiting.
2. Upon task completing, it calls syncContext.Post() to resume "Where you were before"


Problem :- 
1. DeadLock

The root cause of this deadlock is due to the way await handles contexts. By default, when an incomplete Task is awaited, the current “context” is captured and used to resume the method when the Task completes. This “context” is the current SynchronizationContext unless it’s null, in which case it’s the current TaskScheduler. GUI and ASP.NET applications have a SynchronizationContext that permits only one chunk of code to run at a time. When the await completes, it attempts to execute the remainder of the async method within the captured context. But that context already has a thread in it, which is (synchronously) waiting for the async method to complete. They’re each waiting for the other, causing a deadlock

  public static class DeadlockExample
    {
        private static async Task RunAsync()
        {
            await Task.Delay(1000);
        }
        // This method causes a deadlock when called in a GUI or ASP.NET context.
        public static void Test()
        {
            // Start the delay.
            var task = Runsync();
            // Wait for the delay to complete.
            task.Wait();
        }

    }

Solution :-  we can use "await task.configurationAwait(false).

  public ConfiguredTaskAwaitable ConfigureAwait(bool continueOnCapturedContext)
    {
      return new ConfiguredTaskAwaitable(this, continueOnCapturedContext);
    }

This suppresses step 2, instead if it resumes "on thread that completed  the tasks"

Principles :- UI messgage-queue is an app global resource. To much use will hurt UI responsiveness.

Guidance:- If your method calls chatty async apis. but doesn't touch the UI, then use configurationAwait(false)

2. Performance :- By using ConfigureAwait, This enable small amount of parallelism: Some asynchronous code can run in parallel with the GUI thread instead of constantly badgering it with bits of work to do.