5

I understand that calling ConfigureAwait(false) on a task that is being awaited will sometimes have a performance benefit, as it prevents an unnecessary return to the original SynchroniZationContext.

For example:

async Task Something()
{
   // Let's say I'm on the UI context
   //...
   await AnotherTask.ConfigureAwait(false);

   // Code here is no longer running on the UI context.
   // It runs in a thread pool synchronization context (i.e. null).
}

My question is this: If the task call is on the last line of the method, and we skip the ConfigureAwait(false), is the compiler smart enough to prevent an unnecessary return to the original context?

async Task Something()
{
   // Let's say I'm on the UI context
   //...
   await AnotherTask; // Dropped -> .ConfigureAwait(false);        
}

Will there be a performance penalty or potential deadlock possible here, even though there is nothing in the method after the await call?

Brandon Minnick
  • 13,342
  • 15
  • 65
  • 123
Paymon
  • 1,173
  • 1
  • 9
  • 26

1 Answers1

8

is the compiler smart enough to prevent an unnecessary return to the original context?

Not yet.

Will there be a performance penalty or potential deadlock possible here, even though there is nothing in the method after the await call?

Yes.

Stephen Cleary
  • 437,863
  • 77
  • 675
  • 810
  • Thanks Stephen for your clear and to-the-point response. I also just bought your Concurrency in C# Cookbook from Amazon to sharpen my knowledge :) – Paymon Jan 28 '17 at 10:05
  • May I invite you to look at this question as well :) http://stackoverflow.com/questions/41908593/is-there-any-way-to-see-the-full-stack-trace-across-multiple-threads?noredirect=1#comment70998869_41908593 – Paymon Jan 28 '17 at 11:05