Thread by @_benjaminowen

Ready for "correcting common async/await mistakes in .NET" by @TheCodeTraveler. #NDCOslo

The thread pool is managed by synchronisation context

Maximum number of threads governed by available virtual memory

Doing long-running work on a background thread is important to keep the UI thread available for user interaction

C# compiler generates a state machine (class implementing IAsyncStateMachine) from an await statement

Generated MoveNext() method is a big switch statement - a case for each time we use "await"

Non-awaited tasks hide exceptions

Never call Wait() on a Task

If you need to call an async method synchronously, use GetAwaiter().GetResult(). This gives us correct exception handling

Use ConfigureAwait(false) to avoid having to synchronise on the calling thread

Use ConfigureAwait(false) everywhere except the UI

If an async method doesn't do anything other than await another method, we can just return the Task directly to avoid a context switch

Don't do this from inside try/catch or using blocks

If the hot path in a method does not use the await keyword, return a ValueTask instead.

Don't call async Task methods from the constructor. Constructors should be fast.

async void should be avoided most of the time because exceptions won't be caught

Intellisense doesn't differentiate between void and async void

Non-UI applications won't have a SynchronizationContext, so don't need ConfigureAwait(false)

ConfigureAwait(false) needs to be called after every await, all the way down the method tree

Check out blog.stephencleary.com/2013/11/there-…