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?
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.
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With