Hacker News Reader

Comment by marijnz0r | Hacker News Reader

Although it seems async/await is based on multithreading, this is not the case. To learn about this, read this blog post: https://blog.stephencleary.com/2013/11/there-is-no-thread.ht... Please let me know what you think.

View on HN

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/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.

The event loop behind async await is completely equivalent to thread scheduler.

An event loop is one possible way to implement an async/await executor, but by far not the only way, or even necessarily the most widely used.

Either we have vastly different definitions for event loop or my imagination is very limited.

> It is a form of cooperative multithreading

This is not correct.

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.

The code after an await often gets executed in a different thread based on my logging.

Reply on news.ycombinator.com