←back to thread

Asynchrony is not concurrency

(kristoff.it)
293 points kristoff_it | 3 comments | 18 Jul 25 19:21 UTC | HN request time: 0s | source
Show context
sedatk ◴[18 Jul 25 21:08 UTC] No.44609850[source]▶
Blocking async code is not async. In order for something to execute "out of order", you must have an escape mechanism from that task, and that mechanism essentially dictates a form of concurrency. Async must be concurrent, otherwise it stops being async. It becomes synchronous.
replies(3): >>44610133 #>>44610169 #>>44610264 #
didibus ◴[18 Jul 25 21:46 UTC] No.44610169[source]▶
If you need to do A and then B in that order, but you're doing B and then A. It doesn't matter if you're doing B and then A in a single thread, the operations are out of sync.

So I guess you could define this scenario as asynchronous.

replies(1): >>44610277 #
jayd16 ◴[18 Jul 25 21:59 UTC] No.44610277[source]▶
So wait, is the word they mean by asynchrony actually the word "dependency"?
replies(2): >>44610364 #>>44610973 #
Jtsummers ◴[18 Jul 25 22:15 UTC] No.44610364[source]▶
> So wait, is the word they mean by asynchrony actually the word "dependency"?

No, the definition provided for asynchrony is:

>> Asynchrony: the possibility for tasks to run out of order and still be correct.

Which is not dependence, but rather independence. Asynchronous, in their definition, is concurrent with no need for synchronization or coordination between the tasks. The contrasted example which is still concurrent but not asynchronous is the client and server one, where the order matters (start the server after the client, or terminate the server before the client starts, and it won't work correctly).

replies(2): >>44610440 #>>44610467 #
1. kristoff_it ◴[18 Jul 25 22:23 UTC] No.44610440[source]▶
> The contrasted example which is still concurrent but not asynchronous is the client and server one

Quote from the post where the opposite is stated:

> With these definitions in hand, here’s a better description of the two code snippets from before: both scripts express asynchrony, but the second one requires concurrency.

You can start executing Server.accept and Client.connect in whichever order, but both must be running "at the same time" (concurrently, to be precise) after that.

replies(1): >>44610555 #
2. Jtsummers ◴[18 Jul 25 22:37 UTC] No.44610555[source]▶
Your examples and definitions don't match then.

If asynchrony, as I quoted direct from your article, insists that order doesn't matter then the client and server are not asynchronous. If the client were to execute before the server and fail to connect (the server is not running to accept the connection) then your system has failed, the server will run later and be waiting forever on a client who's already died.

The client/server example is not asynchronous by your own definition, though it is concurrent.

What's needed is a fourth term, synchrony. Tasks which are concurrent (can run in an interleaved fashion) but where order between the tasks matters.

replies(1): >>44610617 #
3. kristoff_it ◴[18 Jul 25 22:45 UTC] No.44610617[source]▶
> If the client were to execute before the server and fail to connect (the server is not running to accept the connection) then your system has failed, the server will run later and be waiting forever on a client who's already died.

From the article:

> Like before, the order doesn’t matter: the client could begin a connection before the server starts accepting (the OS will buffer the client request in the meantime), or the server could start accepting first and wait for a bit before seeing an incoming connection.

When you create a server socket, you need to call `listen` and after that clients can begin connecting. You don't need to have already called `accept`, as explained in the article.