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.
Asynchrony is not concurrency
41–50 of 228 posts
Re: Asynchrony is not concurrency
#42One thing that most languages are lacking is expressing lazy return values. -> await f1() + await f2() and to express this concurently requres manually handing of futures.
Which languages do have such a thing?
Re: Asynchrony is not concurrency
#43The 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!
Re: Asynchrony is not concurrency
#44IMO 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.
Can't we just call that "independent"?
Re: Asynchrony is not concurrency
#45Earlier 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…
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.
Re: Asynchrony is not concurrency
#46The 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…
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 concurrent vs parallel we would have exactly the same level of understanding of the actual details of what code is doing, and we would have exactly the same level of understanding about the theory of what is going on. It's trying to impose two categories that just don't cleanly line up with any real system, and it's trying to create definitions that just aren't natural in any real system.
Parallel vs concurrent is a bad and useless thing to talk about. It's a waste of time. It's much more useful to talk about what operations in a system can overlap each other in time and which operations cannot overlap each other in time. The ability to overlap in time might be due to technical limitations (python GIL), system limitations (single core processor) or it might be intentional (explicit locking), but that is the actual thing you need to understand, and parallel vs concurrent just gives absolutely no information or insights whatsoever.
Here's how I know I'm right about this: Take any actual existing software or programming language or library or whatever, and describe it as parallel or concurrent, and then give the extra details about it that isn't captured in "parallel" and "concurrent". Then go back and remove any mention of "parallel" and "concurrent" and you will see that everything you need to know is still there, removing those terms didn't actually remove any information content.
Re: Asynchrony is not concurrency
#47Earlier quoted context omitted.
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.
careful: in many programming contexts parallelism and concurrency are exclusive concepts, and sometimes under the umbrella of async, which is a term that applies to a different domain. in other contexts these words don't describe disjoint sets of things so it's important to clearly define your terms when talking about software.
yes, some people swap the meaning of concurrency and asynchrony. But, almost all implementations of async use main event loops, global interpreter lock, co-routines etc. and thus at the end of the day only do one thing at a time.
Therefore I think this definition makes the most sense in practical terms. Defining concurrency as the superset is a useful construct because you have to deal with the same issues in both cases. And differentiating asynchrony and parallelism makes sense because it changes the trade-off of latency and energy consumption (if the bandwidth is fixed).
Re: Asynchrony is not concurrency
#48Earlier quoted context omitted.
careful: in many programming contexts parallelism and concurrency are exclusive concepts, and sometimes under the umbrella of async, which is a term that applies to a different domain. in other contexts these words don't describe disjoint sets of things so it's important to clearly define your terms when talking about software.
Yeah concurrency is not parallelism. https://go.dev/blog/waza-talk
That is compatible with my statement: Not all concurrency is parallelism, but all parallelism is concurrency.
Re: Asynchrony is not concurrency
#49One thing that most languages are lacking is expressing lazy return values. -> await f1() + await f2() and to express this concurently requres manually handing of futures.
That's because f2's result could depend on whether f1 has executed.
Re: Asynchrony is not concurrency
#50Earlier quoted context omitted.
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
Concurrency implies asynchrony (two systems potentially doing work at the same time withut waiting for each other), but the converse is not true. A single process can do work in an unordered (asynchronous) way.
Parallelism implies concurrency but not does not imply asynchrony.