The async and await keywords don't cause additional threads to be created?

Question

I'm confused. How can one or many Task run in parallel on a single thread? My understanding of parallelism is obviously wrong.

Bits of MSDN I can't wrap my head around:

The async and await keywords don't cause additional threads to be created. Async methods don't require multithreading because an async method doesn't run on its own thread. The method runs on the current synchronization context and uses time on the thread only when the method is active.

.. and:

Between starting a task and awaiting it, you can start other tasks. The additional tasks implicitly run in parallel, but no additional threads are created.

Novotny

Answer 1

They don't run in parallel, they take turns. When progress is blocked for the running Task, it stores its state and yields control to a ready Task. It's cooperative multitasking, not true parallelism.

Threads operate on the sample principle. However there are several key differences I'd like to highlight.

First, simply because async/await aren't OS threads:

• Tasks won't see different Thread IDs
• Thread-local storage is not automatically context-switched when a Task yields.

Secondly, differences in behavior:

• async/await use cooperative multitasking, Win32 threads use pre-emption. So it's necessary that all blocking operations explicitly yield control using the async/await model. So you can end up blocking an entire thread and all its Tasks by making a blocking call to a function not written to yield.
• Tasks won't be executed in parallel on a multiprocessing system. Since re-entrancy is controlled, this makes keeping data structures consistent a whole lot easier.

As Stephen points out in a comment, you can get simultaneous execution in multiple OS threads (along with all the complexity and potential race conditions) if you use a multithreaded synchronization context. But the MSDN quotes were about the single-threaded context case.

Finally, other places this same design paradigm is used, you can learn a lot about good practices for async/await by studying these:

• Win32 Fibers (uses the same call style as threads, but cooperative)
• Win32 Overlapped I/O operations, Linux aio
• Coroutines

Posthaste

"blocked" might be a confusing term to use here, since the goal of async is to avoid blocking. – Lamellibranch

+1. Note that the async method saves its state and yields when it is blocked on an await. If it's running blocking code (like Thread.Sleep), then it won't save its state and yield. – Joyjoya

@Cory: Individual Tasks get blocked, the thread doesn't (as Stephen says, this is true only if you use coroutines for everything). – Posthaste

I think that it should be made clear, why MS WROTE this. Many people think, that "async" makes a method run asynchronously (on a separate thread). No it doesnt. And also await SomeMethodAsync() doesn't create a new thread, just because of AWAIT. A new thread is created if SomeMethodAsync creates a new thread (which it does not necessarily do) – Stranger

Yes, not arguing about correctness, just suggesting to reduce ambiguity on what you mean by "block" (as Stephen did, +1). – Lamellibranch

@BenVoigt: A lot of your updated answer is only true for async methods executed within a single-threaded SynchronizationContext (such as a UI context). If they are run in a console app or from a background thread, then Tasks will execute on the thread pool and will execute in parallel (on multiple threads) unless you await each one individually. – Joyjoya

@BenVoigt thanks Ben, I will look into "cooperative multitasking" and "coroutines". It'll take me some time to dive into those concepts. I'll be right back. – Novotny

@Stephen: Updated somewhat. These MSDN quotes would be just plain wrong with a context linked to the thread pool, wouldn't they? – Posthaste