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

21–30 of 228 posts

Re: Asynchrony is not concurrency

#21

Post by tines »

threatofrain wrote: post #17
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.

Concurrency is the property of a program to be divided into partially ordered or completely unordered units of execution. It does not describe how you actually end up executing the program in the end, such as if you wish to exploit these properties for parallel execution or task switching. Or maybe you're running on a single thread and not doing any task switching or parallelism. For more I'd look up Rob Pike's discu…

The article understands this.

Re: Asynchrony is not concurrency

#22

Post by andsoitis »

tines wrote: post #9
threatofrain wrote: post #2

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

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.

Asynchrony is when things don't happen at the same time or in the same phase, i.e. is the opposite of Synchronous. It can describe a lack of coordination or concurrence in time, often with one event or process occurring independently of another.

The correctness statement is not helpful. When things happy asynchronously, you do not have guarantees about order, which may be relevant to "correctness of your program".

Re: Asynchrony is not concurrency

#23

Post by Retr0id »

tines wrote: post #16
koakuma-chan wrote: post #13

Earlier quoted context omitted.

Example 1 You can write to one file, wait, and then write to the second file. Concurrency not required. Example 2 You can NOT do Server.accept, wait, and then do Client.connect, because Server.accept would block forever. Concurrency required.

Oh, I see. The article is saying that async is required. I thought it was saying that parallelism is required. The way it's written makes it seem like there's a problem with the code sample, not that the code sample is correct.

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 concurrent programs. I think I'll have to learn more about how async works in zig.

Re: Asynchrony is not concurrency

#24

Post by butterisgood »

ioasuncvinvaer wrote: post #3

Is there anything new in this article?

Perhaps not, but sometimes the description from a different angle helps somebody understand the concepts better.

I don't know how many "monad tutorials" I had to read before it all clicked, and whether it ever fully clicked!

Re: Asynchrony is not concurrency

#25

Post by Lichtso »

tines wrote: post #9
threatofrain wrote: post #2

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

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.

Concurrency is parallelism and/or asynchrony, simply the superset of the other two.

Asynchrony means things happen out of order, interleaved, interrupted, preempted, etc. but could still be just one thing at a time sequentially.

Parallelism means the physical time spent is less that the sum of the total time spent because things happen simultaneously.

Re: Asynchrony is not concurrency

#26

Post by jkcxn »

tines wrote: post #9
threatofrain wrote: post #2

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

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.

Not the OP, but in formal definitions like Communicating Sequential Processes, concurrency means the possibility for tasks to run out of order and still be correct, as long as other synchronisation events happen

Re: Asynchrony is not concurrency

#27

Post by threatofrain »

tines wrote: post #21
threatofrain wrote: post #17

Earlier quoted context omitted.

Concurrency is the property of a program to be divided into partially ordered or completely unordered units of execution. It does not describe how you actually end up executing the program in the end, such as if you wish to exploit these properties for parallel execution or task switching. Or maybe you're running on a single thread and not doing any task switching or parallelism. For more I'd look up Rob Pike's discu…

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.

Re: Asynchrony is not concurrency

#28

Post by sapiogram »

threatofrain wrote: post #2

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

This is why I've completely stopped using the term, literally everyone I talk to seems to have a different understanding. It no longer serves any purpose for communication.

Re: Asynchrony is not concurrency

#29

Post by chowells »

ltbarcly3 wrote: post #4

The argument about concurrency != parallelism mentioned in this article as being "not useful" is often quoted and rarely a useful or informative, and it also fails to model actual systems with enough fidelity to even be true in practice. Example: python allows concurrency but not parallelism. Well not really though, because there are lots of examples of parallelism in python. Numpy both releases the GIL and internall…

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 hard, so we define models that allow single-purpose chunks of linear code to interleave and then allow the language, libraries, and operating system to handle the details. Yes, even the operating system. How do you think multitasking worked before multi-core CPUs? The kernel had a fancy state machine tracking execution of multiple threads that were allowed to interleave. (It still does, really. Adding multiple cores only made it more complicated.)

Parallelism is running code on multiple execution units. That is execution. It doesn't matter how it was written; it matters how it executes. If what you're doing can make use of multiple execution units, it can be parallel.

Code can be concurrent without being parallel (see async/await in javascript). Code can be parallel without being concurrent (see data-parallel array programming). Code can be both, and often is intended to be. That's because they're describing entirely different things. There's no rule stating code must be one or the other.

Re: Asynchrony is not concurrency

#30

Post by sunshowers »

Retr0id wrote: post #23
tines wrote: post #16

Earlier quoted context omitted.

Oh, I see. The article is saying that async is required. I thought it was saying that parallelism is required. The way it's written makes it seem like there's a problem with the code sample, not that the code sample is correct.

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 "threads" and "malloc" aren't meaningful concepts.

Rust does have a notion of autonomous existence: tasks.

Post reply on HN