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

211–220 of 228 posts

Re: Asynchrony is not concurrency

#211

Post by jayd16 »

raluk wrote: post #148
jayd16 wrote: post #70

Earlier quoted context omitted.

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.

This is what i hand in mind whit "manually handing of futures". In this case you have to write Promise1 = f1(); Promise2 = f2(); v1,v2 = await Join(Promise1, Promise2); return v1 + v2 I think this is just too much of synthactic noise. On the other hand, it is necessary becase some of underlying async calls can be order dependend. for example await sock.rec(1) == 'A' && await sock.rec(1) == 'B' checks that first recei…

I suppose you'd have to make

    SumAsync(F1(),f2());
Buy it's kind of intractable, isn't it? Your language has to assume order dependency or independency and specify the other. Most seem to stick with lexical ordering implies execution order.

I think some use curly brace scoping to break up dependency. I want to say kotlin does something like this.

This is why they say async is a viral pattern but IMO that's because you're adding specificity and function coloring is necessary and good.

Re: Asynchrony is not concurrency

#212

Post by YZF »

Yoric wrote: post #163
atoav wrote: post #162

Earlier quoted context omitted.

I am not deep into the matter but I would have given the answer: Async code is making code that would have been blocking non-blocking in a manner other stuff can still happen while it is being completed. Since I work a lot in embedded loops where long running blocking snippets could literally break your I/O, lead to visible/audible dropouts etc. this would be the obvious answer.

But that's the thing: async, by itself, doesn't guarantee that anything is non-blocking. For your fiber (or any other kind of user-land abstraction) to be non-blocking, you MUST ensure that it doesn't perform any blocking call. All async does is give you (some of) the tools to make code non-blocking.

You can run blocking code asynchronously from other code. I think the parent means something like if you have a blocking operation (function call e.g.) on a thread you can create another thread and run that blocking operation there, magically transforming a blocking call to something that looks like a non-blocking call (thus allowing other code to do something else instead of waiting)

Re: Asynchrony is not concurrency

#213

Post by YZF »

Yoric wrote: post #178
atoav wrote: post #170

Earlier quoted context omitted.

Yeah, sure I mean in embedded-land any async snippet could perform any number of things, like firing a delay command that puts the whole processor to sleep. This could potentially be avoided by clever enough compilers or runtimes, but I am not sure whether that would really be benefitial. I am a fan of making things explicit, so the closer peoples idea of what aync is and what it isn't matches reality the better. Alt…

Yeah, I'm insisting because I recently reviewed a PR with async code calling blocking code, which made the entire exercise pointless. And that was from an experienced dev. There used to be a few compilers that used static analysis to predict the cost of a call (where the cost of I/O was effectively considered infinite) and in which you could enforce that a branch only had a budget of N. Modern architectures tend to m…

The entire point might be to offload the blocking call and do something else while it's blocking.

There's a style of "asynchronous programming" where everything is designed to be non-blocking and there can be asynchronous programming with blocking code. In fact the first style can be emulated by offloading every blocking call to a different thread/greenthread/fiber and that's basically what's happening under the hood unless there is some fundamental support for non-blocking at the lower levels (sometimes all the way down to the hardware).

Re: Asynchrony is not concurrency

#214

Post by alfiedotwtf »

sdbrady wrote: post #210
alfiedotwtf wrote: post #202

Earlier quoted context omitted.

> Usually, ordering of operations in code is indicated by the line number (first line happens before the second line, and so on), but I understand that this might fly out the window in async code This isn’t always true at the language level, and almost certainly not at the CPU pipeline and microcode level. Logic languages like Prolog will execute statements out of order, by design. Other languages like Mercury use th…

I'm not sure what you mean by "statements" in Prolog as it's not a term the language defines. If you're referring to clauses, it's not true that execution is unordered: the Prolog interpreter attempts to unify a goal with clauses from the knowledge base in the order they appear. This ordering is semantically significant for control flow. If instead you're referring to goals within the body of a clause, this is also i…

> the Prolog interpreter attempts to unify a goal with clauses from the knowledge base in the order they appear.

I was under the impression that when plugging holes during unification, that these statements/clauses could happen in any order just as you would like solving a crossword puzzle

Re: Asynchrony is not concurrency

#215

Post by saghm »

ajross wrote: post #188
saghm wrote: post #149

Earlier quoted context omitted.

You're not reporting yourself, though, since you didn't make it clear at all in your initial comment you were talking about hardware. The previous comment you made only mentioned "parallel data races" in a conversation about software ecosystems, where both of those terms are regularly used to describe things that occur. You're laughing about dunking on people who you've run up to in the middle of a football field; no…

The term "hardware-parallel" was to clarify that I'm talking about genuine parallelism. SMP bugs are 100% software problems solved with software techniques. You learn about them in software courses in school. They're just much harder than getting your async rig to work.

You're probably right. I just don't think it was nearly as clear what you were talking about before as you seemed to be saying afterwards, so it came across as needlessly smug when clarifying like you did here would have been more than sufficient.

Re: Asynchrony is not concurrency

#216

Post by lowbloodsugar »

>Asynchrony: the possibility for tasks to run out of order and still be correct.

This is simply wrong. Asynchrony makes no claims about two unrelated tasks, so “order” here is irrelevant and in terms of each task, again, we expect the executions of a given task to be in order. So this statement cannot be true under either interpretation.

There’s lots more wrong with the article as you would expect when the starting premise is wrong.

Re: Asynchrony is not concurrency

#217

Post by gf000 »

ddingus wrote: post #183

I do not see these definitions as quite right: >Asynchrony: the possibility for tasks to run out of order and still be correct. I like this. Great addition and yes it was missing. >Concurrency: the ability of a system to progress multiple tasks at a time, be it via parallelism or task switching. I would say here, be it multiprocessing or task switching. >Parallelism: the ability of a system to execute more than one t…

A single-threaded CPU can do concurrent processing just fine - this is an important distinction compared to parallelism, and I think you are muddying the two up a bit here.

Re: Asynchrony is not concurrency

#218

Post by gf000 »

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…

That leaves out the (partial) ordering of "operations". Happens before/after/at the same time is just one important primitive.

Re: Asynchrony is not concurrency

#219

Post by ddingus »

gf000 wrote: post #217
ddingus wrote: post #183

I do not see these definitions as quite right: >Asynchrony: the possibility for tasks to run out of order and still be correct. I like this. Great addition and yes it was missing. >Concurrency: the ability of a system to progress multiple tasks at a time, be it via parallelism or task switching. I would say here, be it multiprocessing or task switching. >Parallelism: the ability of a system to execute more than one t…

A single-threaded CPU can do concurrent processing just fine - this is an important distinction compared to parallelism, and I think you are muddying the two up a bit here.

I agree with you and thought I was clear on that.

In fact, there is no effective difference between a very fast single thread, sequential compute CPU and a multiprocessor, or multi-core CPU.

Re: Asynchrony is not concurrency

#220

Post by JackSlateur »

"asynchrony is not concurrency" : this is true

What is also true is that asynchrony without concurrency is harmful

I might be more precise: asynchrony without parallelism is harmful, because you introduce a whole new set of computing operations without any benefits

Post reply on HN