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 :

When you’re doing asynchronous work, you’re not always using a thread.
For example, when you make an asynchronous web service request,
ASP.NET will not be using any threads between the async method call
and the await.

So what I am trying to understand is, how does it become async if we don’t use any Threads for concurrent execution? What does it mean “you’re not always using a thread.”?

Let me first explain what I know regarding working with threads (A quick example, of course Threads can be used in different situations other than UI and Worker methodology here)

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 create a new worker thread which downloads the file and changes the progress bar.
6. Once it is done, there is nothing to do so thread is killed.
7. We continue from UI thread.

We can either wait for the worker thread in UI thread depending on the situation but before that while the file is being downloaded, we can do other things with UI thread and then wait for the worker thread.

Isn’t the same for async programming? If not, what’s the difference? I read that async programming uses ThreadPool to pull threads from though.

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.