Improved async/await usage

[patroza]

Added .ConfigureAwait(false) to awaits. As libraries should leave context switching up to callers instead.

Removed async/await where unneeded. As this generates statemachines needlessly.

[mhinze]

I'm all for optimizations like this, but I need more information about how ConfigureAwait(false) will impact calling code using ASP.NET - I'll give this to our team and do some more research.

[patroza]

Thanks for response mhinze!

To the best of my knowledge this will not affect any consumer negatively, because the context switching back will still occur at the caller unless the caller also adds ConfigureAwait(false) to his call.

So in essence, by adding .ConfigureAwait(false) to the library, you leave the control at the caller (and the latest possible moment) who can take appropriate action (adding ConfigureAwait(false) from other libraries/utility methods, and ommitting it in ASP.NET Controllers or WPF UI actions etc).

Sources:

• http://stackoverflow.com/questions/13489065/best-practice-to-call-configureawait-for-all-server-side-code
• http://blog.stephencleary.com/2012/07/dont-block-on-async-code.html
• http://msdn.microsoft.com/en-us/magazine/jj991977.aspx

[akamud]

Indeed, basically the rule of thumb is: do not capture the context unless you need it. So using ConfigureAwait(false) is a best practice as @sickboy said. This will prevent deadlocks.

As for the others optimizations, as described here, awaiting the return isn't needed, so removing that increases performance because it won't have to generate the machine state for that method call.