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

101–110 of 228 posts

Re: Asynchrony is not concurrency

#101

Post by dooglius »

dvt wrote: post #87

"Asynchrony" is a very bad word for this and we already have a very well-defined mathematical one: commutativity. Some operations are commutative (order does not matter: addition, multiplication, etc.), while others are non-commutative (order does matter: subtraction, division, etc.). try io.asyncConcurrent(Server.accept, .{server, io}); io.async(Cient.connect, .{client, io}); Usually, ordering of operations in code…

Commutativity is a much weaker claim because one is totally before or after the other. e.g. AB may commute with C so ABC=CAB but it is not necessarily the case that this equals ACB. With asynchrony you are guaranteed ABC=ACB=CAB. (There may be an exisiting mathematical term for this but I don't know it)

Re: Asynchrony is not concurrency

#102

Post by xscott »

ryandv wrote: post #97
dvt wrote: post #87

"Asynchrony" is a very bad word for this and we already have a very well-defined mathematical one: commutativity. Some operations are commutative (order does not matter: addition, multiplication, etc.), while others are non-commutative (order does matter: subtraction, division, etc.). try io.asyncConcurrent(Server.accept, .{server, io}); io.async(Cient.connect, .{client, io}); Usually, ordering of operations in code…

Strictly speaking commutativity is defined over (binary) operations - so if one were to say that two async statements (e.g. connect/accept) are commutative, I would have to ask, "under what operation?" Currently my best answer for this is the bind (>>=) operator (including, incidentally, one of its instances, `.then(...)`), but this is just fuzzy intuition if anything at all.

> "under what operation?"

You could treat the semicolon as an operator, and just like multiplication over matrices, it's only commutative for a subset of the general type.

Re: Asynchrony is not concurrency

#103

Post by didibus »

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

Not necessarily, but I guess it depends how you define "dependency".

For example, it might be partial ordering is needed only, so B doesn't fully depend on A, but some parts of B must happen after some parts of A.

It also doesn't imply necessarily that B is consuming an output from A.

And so on.

But there is a dependency yes, but it could be that the behavior of the system depends on both of them happening in some partial ordering.

The difference is with asynchronous, the timing doesn't matter, just the partial or full ordering. So B can happen a year after A and it would eventually be correct, or at least within a timeout. Or in other words, it's okay if other things happen in between them.

With synchronous, the timings tend to matter, they must happen one after the other without anything in-between. Or they might even need to happen together.

Re: Asynchrony is not concurrency

#104

Post by ryandv »

xscott wrote: post #102
ryandv wrote: post #97

Earlier quoted context omitted.

Strictly speaking commutativity is defined over (binary) operations - so if one were to say that two async statements (e.g. connect/accept) are commutative, I would have to ask, "under what operation?" Currently my best answer for this is the bind (>>=) operator (including, incidentally, one of its instances, `.then(...)`), but this is just fuzzy intuition if anything at all.

> "under what operation?" You could treat the semicolon as an operator, and just like multiplication over matrices, it's only commutative for a subset of the general type.

Right, exactly. It's been said that (>>=) is a programmable semicolon.

[0] https://news.ycombinator.com/item?id=21715426

Re: Asynchrony is not concurrency

#105

Post by dvt »

dooglius wrote: post #101
dvt wrote: post #87

"Asynchrony" is a very bad word for this and we already have a very well-defined mathematical one: commutativity. Some operations are commutative (order does not matter: addition, multiplication, etc.), while others are non-commutative (order does matter: subtraction, division, etc.). try io.asyncConcurrent(Server.accept, .{server, io}); io.async(Cient.connect, .{client, io}); Usually, ordering of operations in code…

Commutativity is a much weaker claim because one is totally before or after the other. e.g. AB may commute with C so ABC=CAB but it is not necessarily the case that this equals ACB. With asynchrony you are guaranteed ABC=ACB=CAB. (There may be an exisiting mathematical term for this but I don't know it)

You can prove three-term commutativity from two-term (I did it years ago, I think it looked something like this[1]), so the ordering doesn't matter.

[1] https://math.stackexchange.com/questions/785576/prove-the-co...

Re: Asynchrony is not concurrency

#106

Post by tekbog »

There's a great old book on this if someone wants to check it: Communicating Sequential Processes. From Hoare. Go channels and the concurrent approach was inspired on this.

I also wrote a blog post a while back when I did a talk at work, it's Go focused but still worth the read I think.

[0] https://bognov.tech/communicating-sequential-processes-in-go...

Re: Asynchrony is not concurrency

#107

Post by Spivak »

alerighi wrote: post #96
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!

You don't need mutex in async code, since there is no parallel execution whatsoever. In fact languages that use async programming as a first class citizen (JavaScript) don't even have a construct to do them. If you need to synchronize stuff in the program you can use normal plain variables, since it's guaranteed that your task will be never interrupted till you give control back to the scheduler by performing an awai…

See this is what the OP is getting at, this is only true for async implementations that don't have any parallelism. That doesn't have to be the case, there's no reason that your javascript runtime couldn't take

    await foo()
    await bar()
and execute them in two threads transparently for you. It just happens, like the Python GIL, that it doesn't. Your JS implementation actually already has mutexes because web workers with shared memory bring true parallelization along with the challenges that come with.

Re: Asynchrony is not concurrency

#108

Post by bentleya »

Non-blocking i/o isn't asynchrony and the author should know better. Non-blocking io is a building block of asynchronous systems -- it is not asynchony itself. Today's asynchronous programming did not exist when non-blocking I/O was implemented in Unix in the 80's.

Re: Asynchrony is not concurrency

#109

Post by Ar-Curunir »

dvt wrote: post #105
dooglius wrote: post #101

Earlier quoted context omitted.

Commutativity is a much weaker claim because one is totally before or after the other. e.g. AB may commute with C so ABC=CAB but it is not necessarily the case that this equals ACB. With asynchrony you are guaranteed ABC=ACB=CAB. (There may be an exisiting mathematical term for this but I don't know it)

You can prove three-term commutativity from two-term (I did it years ago, I think it looked something like this[1]), so the ordering doesn't matter. [1] https://math.stackexchange.com/questions/785576/prove-the-co...

Strictly speaking this also requires associativity.
Post reply on HN