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

71–80 of 228 posts

Re: Asynchrony is not concurrency

#71

Post by kazinator »

ryandv wrote: post #40
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.

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 asynchronously submitted result.

Re: Asynchrony is not concurrency

#72

Post by Jtsummers »

jayd16 wrote: post #66
didibus wrote: post #56

Earlier quoted context omitted.

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

Re: Asynchrony is not concurrency

#73

Post by jayd16 »

sunshowers wrote: post #30
Retr0id wrote: post #23

Earlier quoted context omitted.

The article later says (about the server/client example) > Unfortunately this code doesn’t express this requirement [of concurrency], which is why I called it a programming error I gather that this is a quirk of the way async works in zig, because it would be correct in all the async runtimes I'm familiar with (e.g. python, js, golang). My existing mental model is that "async" is just a syntactic tool to express conc…

I think a key distinction is that in many application-level languages, each thing you await exists autonomously and keeps doing things in the background whether you await it or not. In system-level languages like Rust (and presumably Zig) the things you await are generally passive, and only make forward progress if the caller awaits them. This is an artifact of wanting to write async code in environments where "threa…

Thank you so much for the added context. This explains the article very well.

Re: Asynchrony is not concurrency

#74

Post by LegionMammal978 »

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…

I'd count pure one-to-one parallelism as a form of concurrency that doesn't involve any yielding. But otherwise, I agree that all forms of non-parallel concurrency have to be yielding execution at some cadence, even if it's at the instruction level. (E.g., in CUDA, diverging threads in a warp will interleave execution of their instructions, in case one branch tries blocking on the other.)

Re: Asynchrony is not concurrency

#75

Post by kristoff_it »

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…

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

Quote from the article where the exact opposite is stated:

> (and task switching is – by the definition I gave above – a concept specific to concurrency)

Re: Asynchrony is not concurrency

#76

Post by criddell »

butterisgood wrote: post #8

It's kind of true... I can do a lot of things asynchronously. Like, I'm running the dishwasher AND the washing machine for laundry at the same time. I consider those things not occurring at "the same time" as they're independent of one another. If I stood and watched one finish before starting the other, they'd be a kind of synchronous situation. But, I also "don't care". I think of things being organized concurrentl…

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

Re: Asynchrony is not concurrency

#77

Post by kristoff_it »

Jtsummers wrote: post #72
jayd16 wrote: post #66

Earlier quoted context omitted.

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 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 running "at the same time" (concurrently, to be precise) after that.

Re: Asynchrony is not concurrency

#78

Post by jayd16 »

Jtsummers wrote: post #72
jayd16 wrote: post #66

Earlier quoted context omitted.

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

Re: Asynchrony is not concurrency

#79

Post by kristoff_it »

criddell wrote: post #76
butterisgood wrote: post #8

It's kind of true... I can do a lot of things asynchronously. Like, I'm running the dishwasher AND the washing machine for laundry at the same time. I consider those things not occurring at "the same time" as they're independent of one another. If I stood and watched one finish before starting the other, they'd be a kind of synchronous situation. But, I also "don't care". I think of things being organized concurrentl…

> 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.
Post reply on HN