Parent didn't say that "async/await" is based on multithreading, they said "it is multithreading", which is definitely correct. It is a form of cooperative multithreading with the statically enforced restriction that you can only yield when the thread stack contains a single stack frame.
It is true that an async/await task doesn't map 1:1 to an OS thread, but that's neither here nor there.
Async is orthogonal to multithreading. The async runtime's threading model is an implementation detail. e.g. Node is single threaded. In Rust the Tokio async runtime has a configurable threading model.
The article is mostly focused on Dart and C# - maybe you're referring to one of those specific implementations
Again, thread does not imply OS thread. That's only one possible instance of threading. A general thread of execution is just a sequence of continuations executed one after another. This is exactly what an async/await task is.
The fact that multiple lightweight threads map on an heavier weight OS thread like in Node or in Tokio or whatever is neither important nor novel. M:N threading has been a thing for a very long time.
A specialized async/await runtime is a bit different from the typical M:N runtime (which usually tries to transparently mimic the preemptive posix thread medal), but conceptually there isn't much difference.
> . A general thread of execution is just a sequence of continuations executed one after another.
you're using a definition of "thread" that is quite abstract and not at all what is generally meant by most people when discussing these things
> multiple lightweight threads map on an heavier weight thread like in Node
describing Node as implementing M:N threading, while correct in an abstract sense, is not really useful or again, how most people would describe it.
> A specialized async/await runtime is a bit different from the typical M:N runtime... but conceptually there isn't much difference.
sure, conceptually, but again, you're using definitions in a very idiosyncratic and abstract manner. Which is your right, but it's not very persuasive and it's out of touch with how most people talk about these things.
Well, technically Node is N:1. But concretely, what significant difference you see from a async/await runtime and threaded runtime, other than the former requiring yield points to be syntactically marked in code?
I find the developer experience is quite different. Which is actually quite important. In the async runtimes I am familiar with I find managing shared resources and locking much easier.
But maybe I'm missing something here. Do you know of an async runtime and a threaded runtime that do not have significant differences?
Take boost.asio: it is a generic event loop (that can run on one or more OS threads): on top of asio you can run old school manual continuation passing code, promise/future based code, async code using C++20 coroutines (or a macro hack), or more classically multithreaded code using boost.context. You can write the same logical code in any style and the transformation is fairly mechanical.
async/await allows multiple stacks to be active at once within a single thread. It's not a form of multi-threading, which implies the presence of a thread scheduler.
