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

61–70 of 228 posts

Re: Asynchrony is not concurrency

#61

Post by jayd16 »

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 breaking it out into a new term adds confusion, instead of reducing it.

Re: Asynchrony is not concurrency

#62

Post by michaelsbradley »

Lichtso wrote: post #25
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 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.

Asynchrony also practically connotes nondeterminism, but a single-threaded concurrent program doesn't have to exhibit nondeterministic behavior.

Re: Asynchrony is not concurrency

#63

Post by nemothekid »

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.

Consider:

    readA.await
    readB.await
From the perspective of the application programmer, readA "block" readB. They aren't concurrent.

    join(readA, readB).await
In this example, the two operations are interleaved and the reads happen concurrently. The author makes this distinction and I think it's a useful one, that I imagine most people are familiar with even if there is no name for it.

Re: Asynchrony is not concurrency

#64

Post by OkayPhysicist »

Lichtso wrote: post #48
merb wrote: post #39

Earlier quoted context omitted.

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.

What people mean by "concurrency is not parallelism" is that they are different problems. The concurrency problem is defining an application such that it has parts that are not causally linked with some other parts of the program. The parallelism problem is the logistics of actually running multiple parts of your program at the same time. If I write a well-formed concurrent system, I shouldn't have to know or care if two specific parts of my system are actually being executed in parallel.

In ecosystems with good distributed system stories, what this looks like in practice is that concurrency is your (the application developers') problem, and parallelism is the scheduler designer's problem.

Re: Asynchrony is not concurrency

#65

Post by ninetyninenine »

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.

Doesn't multiple tasks at the same time make it simultaneous?

I think there needs to be a stricter definition here.

Concurrency is the ability of a system to chop a task into many tiny tasks. A side effect of this is that if the system chops all tasks into tiny tasks and runs them all in a sort of shuffled way it looks like parallelism.

Re: Asynchrony is not concurrency

#66

Post by jayd16 »

didibus wrote: post #56
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.

So wait, is the word they mean by asynchrony actually the word "dependency"?

Re: Asynchrony is not concurrency

#67

Post by kibwen »

ajross wrote: post #52
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 abou…

> Code runs to completion until it deterministically yields

No, because async can be (quote often is) used to perform I/O, whose time to completion does not need to be deterministic or predictable. Selecting on multiple tasks and proceeding with the one that completes first is an entirely ordinary feature of async programming. And even if you don't need to suffer the additional nondeterminism of your OS's thread scheduler, there's nothing about async that says you can't use threads as part of its implementation.

Re: Asynchrony is not concurrency

#68

Post by kazinator »

Asynchrony, in this context, is an abstraction which separates the preparation and submission of a request from the collection of the result.

The abstraction makes it possible to submit multiple requests and only then begin to inquire about their results.

The abstraction allows for, but does not require, a concurrent implementation.

However, the intent behind the abstraction is that there be concurrency. The motivation is to obtain certain benefits which will not be realized without concurrency.

Some asynchronous abstractions cannot be implemented without some concurrency. Suppose the manner by which the requestor is informed about the completion of a request is not a blocking request on a completion queue, but a callback.

Now, yes, a callback can be issued in the context of the requesting thread, so everything is single-threaded. But if the requesting thread holds a non-recursive mutex, that ruse will reveal itself by causing a deadlock.

In other words, we can have an asynchronous request abstraction that positively will not work single threaded;

1 caller locks a mutex

2 caller submits request

3 caller unlocks mutex

4 completion callback occurs

If step 2 generates a callback in the same thread, then step 3 is never reached.

The implementation must use some minimal concurrency so that it has a thread waiting for 3 while allowing the requestor to reach that step.

Re: Asynchrony is not concurrency

#69

Post by jayd16 »

koakuma-chan wrote: post #13
Retr0id wrote: post #5

I don't get it - the "problem" with the client/server example in particular (which seems pivotal in the explanation). But I am also unfamiliar with zig, maybe that's a prerequisite. (I am however familiar with async, concurrency, and parallelism)

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.

But why is this a novel concept? The idea of starvation is well known and you don't need parallelism for it to effect you already. What does zig actually do to solve this?

Many other languages could already use async/await in a single threaded context with an extremely dumb scheduler that never switches but no one wants that.

I'm trying to understand but I need it spelled out why this is interesting.

Re: Asynchrony is not concurrency

#70

Post by jayd16 »

raluk wrote: post #31

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

you mean like?

   await Join(f1(), f2())
Although more realistically

   Promise1 = f1(); Promise2 = f2();
   await Join(Promise1, Promise2);
But also, futures are the expression of lazy values so I'm not sure what else you'd be asking for.
Post reply on HN