Asynchrony is not concurrency

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.

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.

So wait, is the word they mean by asynchrony actually the word "dependency"?

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

> Which is not dependence, but rather independence

Alright, well, good enough for me. Dependency tracking implies independency tracking. If that's what this is about I think the term is far more clear.

> where the order matters

I think you misunderstand the example. The article states:

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

The one thing that must happen is that the server is running while the request is open. The server task must start and remain unfinished while the client task runs if the client task is to finish.