I've read the advice many times from people smarter than me, and it has few caveats: Always use ConfigureAwait(false)
inside library code. So I'm fairly certain I know the the answer, but I want to be 100%. The scenario is I have a library that thinly wraps some other asynchronous library.
Library code:
public async Task DoThingAsyc() {
// do some setup
return await otherLib.DoThingAsync().ConfigureAwait(false);
}
Application code:
// need to preserve my synchronization context
await myLib.DoThingAync();
// do I have my context here or did my lib lose it?
Example from http://blogs.msdn.com/b/pfxteam/archive/2012/01/20/10259049.aspx
which means you should have your context back after the
await myLib.DoThingAync();
call.If used inconsistently in the logical chain of async calls,
ConfigureAwait(false)
may add redundant context switches (which usually means redundant thread switches). This may happen in the presence of synchronization context, when some async calls on the logical stack useConfigureAwait(false)
and some don't (more here).You still should use
ConfigureAwait(false)
in your code, but you may want to peek into the 3rd party code you're calling and mitigate any inconsistency with something like this:This would add one extra thread switch, but might potentially prevent many others.
Moreover, if you're creating a really thin wrapper like you showed, you may want to implement it like below, without
async/await
at all:No.
The capturing of the
SynchronizationContext
happens onawait
.ConfigureAwait
configures the specificawait
.If the application calls a library's async method and awaits it the SC is captured on the spot regardless of what happens inside the call.
Now, because the async method's synchronous part (which is the part before the first
await
) is executed before a task is returned to be awaited, you can mess around with theSynchronizationContext
there, butConfigureAwait
doesn't do that.In your specific example you seem to be returning the result of
ConfigureAwait
from the async method. That can't happen becauseConfigureAwait
returns theConfiguredTaskAwaitable
struct. If however we change the method return type:Then awaiting it will indeed affect the calling code's await behavior.