Asynchrony is not concurrency

IMO the author is mixed up on his definitions for concurrency.

https://lamport.azurewebsites.net/pubs/time-clocks.pdf

Can you explain more instead of linking a paper? I felt like the definitions were alright.

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

> Concurrency: the ability of a system to progress multiple tasks at a time, be it via parallelism or task switching.

> Parallelism: the ability of a system to execute more than one task simultaneously at the physical level.

They're just different from what Lamport originally proposed. Asynchrony as given is roughly equivalent to Lamport's characterization of distributed systems as partially ordered, where some pairs of events can't be said to have occurred before or after one another.

One issue with the definition for concurrency given in the article would seem to be that no concurrent systems can deadlock, since as defined all concurrent systems can progress tasks. Lamport uses the word concurrency for something else: "Two events are concurrent if neither can causally affect the other."

Probably the notion of (a)causality is what the author was alluding to in the "Two files" example: saving two files where order does not matter. If the code had instead been "save file A; read contents of file A;" then, similarly to the client connect/server accept example, the "save" statement and the "read" statement would not be concurrent under Lamport's terminology, as the "save" causally affects the "read."

It's just that the causal relationship between two tasks is a different concept than how those tasks are composed together in a software model, which is a different concept from how those tasks are physically orchestrated on bare metal, and also different from the ordering of events..

The definition of asynchrony is bad. It's possible for asynchronous requests to guarantee ordering, such that if a thread makes two requests A and B in that order, asynchronously, they will happen in that order.

Asynchrony means that the requesting agent is not blocked while submitting a request in order to wait for the result of that request.

Asynchronous abstractions may provide a synchronous way wait for the asynchronously submitted result.

> The definition of asynchrony is bad. It's possible for asynchronous requests to guarantee ordering, such that if a thread makes two requests A and B in that order, asynchronously, they will happen in that order.

It's true that it's possible - two async tasks can be bound together in sequence, just as with `Promise.then()` et al.

... but it's not necessarily the case, hence the partial order, and the "possibility for tasks to run out of order".

For example - `a.then(b)` might bind tasks `a` and `b` together asynchronously, such that `a` takes place, and then `b` takes place - but after `a` has taken place, and before `b` has taken place, there may or may not be other asynchronous tasks interleaved between `a` and `b`.

The ordering between `a`, `b`, and these interleaved events is not defined at all, and thus we have a partial order, in which we can bind `a` and `b` together in sequence, but have no idea how these two events are ordered in relation to all the other asynchronous tasks being managed by the runtime.