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

81–90 of 228 posts

Re: Asynchrony is not concurrency

#81

Post by omgJustTest »

jayd16 wrote: post #61

I kind of think the author simply pulled the concept of yielding execution out of the definition of concurrency and into this new "asynchrony" term. Then they argued that the term is needed because without it the entire concept of concurrency is broken. Indeed so, but I would argue that concurrency makes little sense without the ability to yield and is therefore intrinsic to it. Its a very important concept but break…

Concurrency does not imply yielding...

Synchronous logic does imply some syncing and yielding could be a way to sync - which is what i expect you mean.

Asynchronous logic is concurrent without sync or yield.

Concurrency and asynchronous logic do not exist - in real form - in von Neumann machines

Re: Asynchrony is not concurrency

#82

Post by ryandv »

kazinator wrote: post #71
ryandv wrote: post #40

Earlier quoted context omitted.

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

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

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

Re: Asynchrony is not concurrency

#83

Post by Jtsummers »

jayd16 wrote: post #78
Jtsummers wrote: post #72

Earlier quoted context omitted.

> 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 in dependence. Asynchronous, in their definition, is concurrent with no need for synchronization or coordination between the tasks. The contrasted example which is still concu…

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

I'm about to reply to the author because his article is actually confusing as written. He has contradictory definitions relative to his examples.

Re: Asynchrony is not concurrency

#84

Post by Jtsummers »

kristoff_it wrote: post #77
Jtsummers wrote: post #72

Earlier quoted context omitted.

> 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 in dependence. Asynchronous, in their definition, is concurrent with no need for synchronization or coordination between the tasks. The contrasted example which is still concu…

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

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.

Re: Asynchrony is not concurrency

#85

Post by skydhash »

amelius wrote: post #44
tines wrote: post #9

Earlier quoted context omitted.

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.

> Asynchrony: the possibility for tasks to run out of order and still be correct. Can't we just call that "independent"?

Not really. There may be some causal relations.

Re: Asynchrony is not concurrency

#87

Post by dvt »

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

Re: Asynchrony is not concurrency

#88

Post by kristoff_it »

Jtsummers wrote: post #84
kristoff_it wrote: post #77

Earlier quoted context omitted.

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

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

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

Re: Asynchrony is not concurrency

#89

Post by skybrian »

The way I like to think about it is that libraries vary in which environments they support. Writing portable libraries that work in any environment is nice, but often unnecessary. Sometimes you don't care if your code works on Windows, or whether it works without green threads, or (in Rust) whether it works without the standard library.

So I think it's nice when type systems let you declare the environments a function supports. This would catch mistakes where you call a less-portable function in a portable library; you'd get a compile error, indicating that you need to detect that situation and call the function conditionally, with a fallback.

Re: Asynchrony is not concurrency

#90

Post by kazinator »

ryandv wrote: post #82
kazinator wrote: post #71

Earlier quoted context omitted.

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

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

I mean that it's possible in the sense of being designed in as a guarantee; that the async operations issued against some API object will be performed in the order in which they are submitted, like a FIFO queue.

I don't mean "promise.then", whereby the issuance of the next request is gated on the completion of the first.

An example might be async writes to a file. If we write "abc" at the start of the file in one request and "123" starting at the second byte in the second requests, there can be a guarantee that the result will be "a123", and not "abc2", without gating on the first request completing before starting the other.

async doesn't mean out of order; it means the request initiator doesn't synchronize on the completion as a single operation.

Post reply on HN