What lies beneath async/await in C#?
Async/Await is especially important to use in .NET and .NET Core web servers if high concurrency is desired.  .NET uses a managed thread pool that will only spawn up to something like 50 threads quickly by default.  If it sees that more threads are needed, it will slowly add them.<p>This means that a Synchronous web endpoint (think API call that does not use "Async/Await") will hog an entire thread for the life of the request.  I graphed the difference between Synchronous and Asynchronous API endpoints in a blog post last year, and Synchronous endpoints were far less efficient: <a href="https://caleblloyd.com/software/net-core-mvc-thread-pool-vs-async/" rel="nofollow">https://caleblloyd.com/software/net-core-mvc-thread-pool-vs-...</a><p>Note that just because endpoints are declared as "async" does not automatically make them efficient - Asynchronous I/O must be used all the way to the lowest level.  This can be an issue when using library code that you don't control.  For example, Oracle's official MySQL package provides "async" methods, but it uses Synchronous I/O in these methods.  Therefore, "async" calls into their library will really cause synchronous performance.<p>Async/Await is a really cool feature of C#, but I wish that the language had more protection that forced users to do things "the right way", like disallowing Synchronous I/O in async methods.  In order to write libraries that do I/O properly that include both Synchronous and Asynchronous methods, maintainers have to write two separate implementations of the same logic, which is a bit of a pain.