Asynchrony is not concurrency

(kristoff.it)

Show context

dvt ◴[18 Jul 25 22:44 UTC] No.44610616[source]▶

"Asynchrony" is a very bad word for this and we already have a very well-defined mathematical one: commutativity. Some operations are commutative (order does not matter: addition, multiplication, etc.), while others are non-commutative (order does matter: subtraction, division, etc.).

    try io.asyncConcurrent(Server.accept, .{server, io});
    io.async(Cient.connect, .{client, io});

Usually, ordering of operations in code is indicated by the line number (first line happens before the second line, and so on), but I understand that this might fly out the window in async code. So, my gut tells me this would be better achieved with the (shudder) `.then(...)` paradigm. It sucks, but better the devil you know than the devil you don't.

As written, `asyncConcurrent(...)` is confusing as shit, and unless you memorize this blog post, you'll have no idea what this code means. I get that Zig (like Rust, which I really like fwiw) is trying all kinds of new hipster things, but half the time they just end up being unintuitive and confusing. Either implement (async-based) commutativity/operation ordering somehow (like Rust's lifetimes maybe?) or just use what people are already used to.

replies(10): >>44610771 #>>44610939 #>>44612125 #>>44612190 #>>44612605 #>>44612656 #>>44612932 #>>44613047 #>>44613470 #>>44615786 #

1. dooglius ◴[18 Jul 25 23:24 UTC] No.44610939[source]▶

>>44610616 #

Commutativity is a much weaker claim because one is totally before or after the other. e.g. AB may commute with C so ABC=CAB but it is not necessarily the case that this equals ACB. With asynchrony you are guaranteed ABC=ACB=CAB. (There may be an exisiting mathematical term for this but I don't know it)

replies(2): >>44611038 #>>44616889 #

2. dvt ◴[18 Jul 25 23:37 UTC] No.44611038[source]▶

>>44610939 (TP) #

You can prove three-term commutativity from two-term (I did it years ago, I think it looked something like this[1]), so the ordering doesn't matter.

[1] https://math.stackexchange.com/questions/785576/prove-the-co...

replies(2): >>44611317 #>>44612439 #

3. Ar-Curunir ◴[19 Jul 25 00:19 UTC] No.44611317[source]▶

>>44611038 #

Strictly speaking this also requires associativity.

4. dooglius ◴[19 Jul 25 03:51 UTC] No.44612439[source]▶

>>44611038 #

I'm not talking about a universe where all elements commute, I'm talking about a situation in which A, B, and C do not necessarily commute but (AB) and C do. For a rigorous definition: given X and Y from some semigroup G, say X and Y are asynchronous if for any finite decompositions X=Z_{a_1}Z_{a_2}...Z_{a_n} and Y=Z_{b_1}Z_{b_2}...Z_{b_m} (with Z's in G) then for any permutation c_1,...,c_{n+m} of a_1,...,a_n,b_1,...,b_m that preserves the ordering of a's and the ordering of the b's has XY=Z_{c_1}Z_{c_2}...Z_{c_{n+m}}. I make the following claim: if G is commutative then all elements are asynchronous, but for a noncommutative G there can exist elements X and Y that commute (i.e. XY=YX) but X and Y are not asynchronous.

replies(1): >>44613418 #

5. JW_00000 ◴[19 Jul 25 07:43 UTC] No.44613418{3}[source]▶

>>44612439 #

To give a concrete example, matrix multiplication is not commutative in general (AB ≠ BA), but e.g. multiplication with the identity matrix is (AI = IA). So AIB = ABI ≠ BAI.

Or applied to the programming example, the statements:

    1. Server.accept
    2. Client.connect
    3. File.write  # write to completely unrelated file

123 = 312 ≠ 321.

6. jhanschoo ◴[19 Jul 25 16:29 UTC] No.44616889[source]▶

>>44610939 (TP) #

I agree. T and U async with respect to each other means at least that T and U can be broken down into tasks t1, t2, t3, ... tn and u1, u2, ..., un, such that they can be interleaved in any order, but typically we still require that the t tasks are executed in sequential order. The divisions between the tasks are where they give up control, e.g. as they wait for data to be loaded into memory, or on a network call.

This is still a special case of what we mean by async wrt each other, because depending on the interleaving at each step and e.g. the data loaded into memory, the number of tasks may change, but the idea is that they still eventually terminate in a correct state.

↑