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

51–60 of 228 posts

Re: Asynchrony is not concurrency

#51

Post by sunshowers »

m11a wrote: post #45
sunshowers wrote: post #30

Earlier quoted context omitted.

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…

I think that notion is very specific to Rust's design. Golang for example doesn't have that trait, where the user (or their runtime) must drive a future towards completion by polling.

Right, but Go is an application-level language and doesn't target environments where threads aren't a meaningful concept. It's more an artifact of wanting to target embedded environments than something specific to Rust.

Re: Asynchrony is not concurrency

#52

Post by ajross »

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!

> All the pitfalls of concurrency are there [in async APIs]

This is one of those "in practice, theory and practice are different" situations.

There is nothing in the async world that looks like a parallel race condition. Code runs to completion until it deterministically yields, 100% of the time, even if the location of those yields may be difficult to puzzle out.

And so anyone who's ever had to debug and reason about a parallel race condition is basically laughing at that statement. It's just not the same.

Re: Asynchrony is not concurrency

#53

Post by vitaminCPP »

sedatk wrote: post #41

Blocking async code is not async. In order for something to execute "out of order", you must have an escape mechanism from that task, and that mechanism essentially dictates a form of concurrency. Async must be concurrent, otherwise it stops being async. It becomes synchronous.

This is exactly what the article is trying to debunk.

Re: Asynchrony is not concurrency

#54

Post by didibus »

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 think asynchronous as meaning out-of-sync, implies that there needs to be synchronicity between the two tasks.

In that case, asynchronous just means the state that two or more tasks that should be synchronized in some capacity for the whole behavior to be as desired, is not properly in-sync, it's out-of-sync.

Then I feel there can be many cause of asynchronous behavior, you can be out-of-sync due to concurent execution or due to parallel execution, or due to buggy synchronization, etc.

And because of that, I consider asynchronous programming as the mechanisms that one can leverage to synchronize asynchronous behavior.

But I guess you could also think of asynchronous as doesn't need to be synchronized.

Also haven't read the article yet lol

Re: Asynchrony is not concurrency

#55

Post by carodgers »

threatofrain wrote: post #2

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

The author is aware that definitions exist for the terms he uses in his blog post. He is proposing revised definitions. As long as he is precise with his new definitions, this is fine. It is left to the reader to decide whether to adopt them.

Re: Asynchrony is not concurrency

#56

Post by didibus »

sedatk wrote: post #41

Blocking async code is not async. In order for something to execute "out of order", you must have an escape mechanism from that task, and that mechanism essentially dictates a form of concurrency. Async must be concurrent, otherwise it stops being async. It becomes synchronous.

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.

Re: Asynchrony is not concurrency

#58

Post by michaelsbradley »

threatofrain wrote: post #27
tines wrote: post #21

Earlier quoted context omitted.

The article understands this.

> Concurrency: the ability of a system to progress multiple tasks at a time, be it via parallelism or task switching. Okay, but don't go with this definition.

Is the hang up on "at a time"? What if that were changed to something like "in a given amount of time"?

For single threaded programs, whether it is JS's event loop, or Racket's cooperative threads, or something similar, if Δt is small enough then only one task will be seen to progress.

Re: Asynchrony is not concurrency

#59

Post by chowells »

ltbarcly3 wrote: post #46
chowells wrote: post #29

Earlier quoted context omitted.

The difference is quite useful and informative. In fact, most places don't seem to state it strongly enough: Concurrency is a programming model. Parallelism is an execution model. Concurrency is writing code with the appearance of multiple linear threads that can be interleaved. Notably, it's about writing code . Any concurrent system could be written as a state machine tracking everything at once. But that's really…

When you define some concepts, those definitions and concepts should help you better understand and simplify the descriptions of things. That's the point of definitions and terminology. You are not achieving this goal, quite the opposite in fact, your description is confusing and would never actually be useful in understanding, debugging, or writing software. Stated another way: if we just didn't talk about concurren…

Addition vs multiplication is a bad and useless thing to talk about. It's a waste of time. It's much more useful to talk about what number you get at the end. You might get that number from adding once, or twice, or even more times, but that final number is the actual thing you need to understand and "addition vs multiplication" just gives absolutely no information or insights whatsoever.

They're just different names for different things. Not caring that they're different things makes communication difficult. Why do that to people you intend to communicate with?

Re: Asynchrony is not concurrency

#60

Post by WhitneyLand »

carodgers wrote: post #55
threatofrain wrote: post #2

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

The author is aware that definitions exist for the terms he uses in his blog post. He is proposing revised definitions. As long as he is precise with his new definitions, this is fine. It is left to the reader to decide whether to adopt them.

He’s repurposing asynchrony that’s different from the way most literature and many developers use it, and that shift is doing rhetorical work to justify a particular Zig API split.

No thanks.

Post reply on HN