Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Asynchrony is not concurrency

kristoff.it

Post reply on HN
Print view View original

111–120 of 228 posts

Re: Asynchrony is not concurrency

#111

Post by senderista »

dvt wrote: post #98
ryandv wrote: post #97

Earlier quoted context omitted.

Strictly speaking commutativity is defined over (binary) operations - so if one were to say that two async statements (e.g. connect/accept) are commutative, I would have to ask, "under what operation?" Currently my best answer for this is the bind (>>=) operator (including, incidentally, one of its instances, `.then(...)`), but this is just fuzzy intuition if anything at all.

Commutative operations (all of them I think?) are trivially generalized to n-ary operations (in fact, we do this via ∑ and ∏, in the case of addition and multiplication, respectively). You're right that the question of what "operation" we're dealing with here is a bit hazy; but I'd wager that it's probably in the family of the increment operation (N++ === N + 1 = 1 + N) since we're constantly evaluating the next line…

Generalizing an associative binary op to an n-ary op just requires an identity element Id (which isn't always obvious, e.g. Id_AND=true but Id_OR=false).

Re: Asynchrony is not concurrency

#112

Post by criddell »

kristoff_it wrote: post #79
criddell wrote: post #76

Earlier quoted context omitted.

> I consider those things not occurring at "the same time" as they're independent of one another. What would it take for you to consider them as running at the same time then?

That eventually the server and the client are able to connect.

The dishwasher and washing machine?

Re: Asynchrony is not concurrency

#113

Post by noduerme »

ryandv wrote: post #97
dvt wrote: post #87

"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…

Strictly speaking commutativity is defined over (binary) operations - so if one were to say that two async statements (e.g. connect/accept) are commutative, I would have to ask, "under what operation?" Currently my best answer for this is the bind (>>=) operator (including, incidentally, one of its instances, `.then(...)`), but this is just fuzzy intuition if anything at all.

`.then()` is ugly, `await` is pretty, but wouldn't the critical part to guarantee commutivity less than guaranteed order (in js) be the `Promise.all([])` part?

Re: Asynchrony is not concurrency

#114

Post by nemothekid »

I think I'm missing something here, but the most interesting piece here is how would stackless coroutines work in Zig?

Since any function can be turned into a coroutine, is the red/blue problem being moved into the compiler? If I call:

     io.async(saveFileA, .{io});
Is that a function call? Or is that some "struct" that gets allocated on the stack and passed into an event loop?

Furthermore, I guess if you are dealing with pure zig, then its fine, but if you use any FFI, you can potentially end up issuing a blocking syscall anyways.

Re: Asynchrony is not concurrency

#116

Post by skydhash »

amelius wrote: post #86
skydhash wrote: post #85

Earlier quoted context omitted.

Not really. There may be some causal relations.

Can you give an example?

Locks, scheduling,... That introduce some synchronicity and so some kind of order. But it's enforced on the system and not a required mechanism.

Re: Asynchrony is not concurrency

#117

Post by laserbeam »

nemothekid wrote: post #114

I think I'm missing something here, but the most interesting piece here is how would stackless coroutines work in Zig? Since any function can be turned into a coroutine, is the red/blue problem being moved into the compiler? If I call: io.async(saveFileA, .{io}); Is that a function call? Or is that some "struct" that gets allocated on the stack and passed into an event loop? Furthermore, I guess if you are dealing wi…

I hope this is not a bad answer as I tried to understand what stackless coroutines even are for the past week.

1. Zig plans to annotate the maximum possible stack size of a function call https://github.com/ziglang/zig/issues/23367 . As people say, this would give the compiler enough information to implemented stackless coroutines. I do not understand well enough why that’s the case.

2. Allegedly, this is only possible because zig uses a single compilation unit. You are very rarely dealing with modules that are compiled independently. If a function in zig is not called, it’s not compiled. I can see how this helps with point 1.

3. Across FFI boundaries this is a problem in every language. In theory you can always do dumb things after calling into a shared library. A random C lib can always spawn threads and do things the caller isn’t expecting. You need unsafe blocks in rust for the same reason.

4. In theory, zig controls the C std library when compiling C code. In some cases, if there’s only one Io implementation used for example, zig could replace functions in the c std library to use that io vtable instead.

Regardless, I kinda wish kristoff/andrew went over what stackless coroutines are (for dummies) in an article at some point. I am unsure people are talking about the same thing when mentioning that term. I am happy to wait for that article until zig tries to implement that using the new async model.

Re: Asynchrony is not concurrency

#118

Post by User23 »

Asynchrony, parallelism, concurrency, and even deterministic execution (albeit as a degenerate case) are all just species of nondeterminism. Dijkstra and Scholten’s work on the subject is sadly under appreciated. And lest one thing this was ivory tower stuff, before he was a professor Dijkstra was a systems engineer writing operating systems on hilariously bad, by our standards, hardware.

Re: Asynchrony is not concurrency

#119

Post by laserbeam »

tossandthrow wrote: post #43

The author does not seem to have made any non-trivial projects with asynchronicity. All the pitfalls of concurrency are there - in particular when executing non-idempotent functions multiple times before previous executions finish, then you need mutexes!

Mutexes are part of the Io interface in zig. So is sleep, select, network calls, file io, cancellation…

Re: Asynchrony is not concurrency

#120

Post by laserbeam »

threatofrain wrote: post #2

IMO the author is mixed up on his definitions for concurrency. https://lamport.azurewebsites.net/pubs/time-clocks.pdf

Keep in mind that you can’t really express half the concepts in lamport’s papers in most languages. You don’t really talk about total and partial clock ordering when starting a thread. You only really do it in TLA+ when designing a protocol.

That being said, I agree we don’t need a new term to express “Zig has a function in the async API that throws a compilation error when you run in a non-concurrent execution. Zig let’s you say that.” It’s fine to so that without proposing new theory.

Post reply on HN