Programming

Write-up is highly Windows-centric (though not irrelevant elsewhere).

One thing that is regretfully ignored in discussions of async, tasks, green threads, etc. is that there is no support/consideration for native (reliable/efficient) thread-local variables. If you're lucky you'll get a warning about "don't use them".

Even if this was true in 2013, when this article was written, the more accurate answer today would be "it depends".

In Rust, there are multi-threaded async executors implementing M:N threading (e.g. tokio), where M asynchronous tasks are mapped to N operating system threads. So when you await, the rest of the function may very well run in a different OS thread.

Swift also has async/await, and like tokio it uses multiple threads to run concurrent tasks in parallel (therefore using multiple OS threads).

Scala's equivalent to asynchronous tasks are Promises, which can also run in parallel, as I understand it.

Kotlin doesn't have async/await, but it has a similar concept, coroutines, which are basically a superset of asynchronous tasks. While Kotlin's coroutines are single-threaded by default, there is a multi-threaded implementation, enabling truly parallel coroutines.

Go also uses coroutines (which it calls "goroutines"), which can use multiple threads.

C++ will soon get coroutines as well, which support multithreading to run coroutines in parallel.

The article is about .NET async/task and a driver hardware request specifically. I find the post title and article awful.

[…] we see that there was no thread while the request was in flight. When the request completed, various threads were “borrowed” or had work briefly queued to them. […] But there is no thread that was blocked, just waiting for that request to complete.

So there are threads after all.

Now, the path that we followed was the “standard” path, somewhat simplified. There are countless variations, but the core truth remains the same.

No, it doesn't. You can't take one specific use case and code flow analysis and extrapolate to a generic concept and universal truth. You can only make a statement for that type of thing. (And even then have to consider execution may differ for various reasons.)

The idea that “there must be a thread somewhere processing the asynchronous operation” is not the truth.

But the opposite of "there is no thread anywhere ever" is not true either.

For .NET tasks as a concept, an interface, tasks may return immediately not just without thread scheduling but also without task scheduling. Tasks may be scheduled through a thread pool. Or they may be executed like OP analysis.

They completely ignored anything outside their specific case and made a broad claim as if it represented all of them.

If the actual point is that "borrowed threads are not [real] threads" then that's broadly misleading and wrong.