How different async programming is from Threads?

Question

I\'ve been reading some async articles here: http://www.asp.net/web-forms/tutorials/aspnet-45/using-asynchronous-methods-in-aspnet-45 and the author says :

Answer 1

Threads are not necessary for asynchronous programming.

"Asynchronous" means that the API doesn't block the calling thread. It does not mean that there is another thread that is blocking.

First, consider your UI example, this time using actual asynchronous APIs:

1. You have UI Thread to take input, give output.
2. You can handle things in UI Thread but it makes the UI unresponsive.
3. So lets say we have a stream-related operation and we need to download some sort of data.
4. And we also allow users to do other things while it is being downloaded.
5. We use asynchronous APIs to download the file. No worker thread is necessary.
6. The asynchronous operation reports its progress back to the UI thread (which updates the progress bar), and it also reports its completion to the UI thread (which can respond to it like any other event).

This shows how there can be only one thread involved (the UI thread), yet also have asynchronous operations going on. You can start up multiple asynchronous operations and yet only have one thread involved in those operations - no threads are blocked on them.

async/await provides a very nice syntax for starting an asynchronous operation and then returning, and having the rest of the method continue when that operation completes.

ASP.NET is similar, except it doesn't have a main/UI thread. Instead, it has a "request context" for every incomplete request. ASP.NET threads come from a thread pool, and they enter the "request context" when they work on a request; when they're done, they exit their "request context" and return to the thread pool.

ASP.NET keeps track of incomplete asynchronous operations for each request, so when a thread returns to the thread pool, it checks to see if there are any asynchronous operations in progress for that request; if there are none, then the request is complete.

So, when you await an incomplete asynchronous operation in ASP.NET, the thread will increment that counter and return. ASP.NET knows the request isn't complete because the counter is non-zero, so it doesn't finish the response. The thread returns to the thread pool, and at that point: there are no threads working on that request.

When the asynchronous operation completes, it schedules the remainder of the async method to the request context. ASP.NET grabs one of its handler threads (which may or may not be the same thread that executed the earlier part of the async method), the counter is decremented, and the thread executes the async method.

ASP.NET vNext is slightly different; there's more support for asynchronous handlers throughout the framework. But the general concept is the same.

For more information:

• My async/await intro post tries to be both an intro yet also reasonably complete picture of how async and await work.
• The official async/await FAQ has lots of great links that go into a lot of detail.
• The MSDN magazine article It's All About the SynchronizationContext exposes some of the plumbing underneath.