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

221–228 of 228 posts

Re: Asynchrony is not concurrency

#221

Post by butterisgood »

criddell wrote: post #76
butterisgood wrote: post #8

It's kind of true... I can do a lot of things asynchronously. Like, I'm running the dishwasher AND the washing machine for laundry at the same time. I consider those things not occurring at "the same time" as they're independent of one another. If I stood and watched one finish before starting the other, they'd be a kind of synchronous situation. But, I also "don't care". I think of things being organized concurrentl…

> I consider those things not occurring at "the same time" as they're independent of one another. What would it take for you to consider them as running at the same time then?

Actually running at the same time is parallelism. "Logically" running at the same time would be "asynchronous". It has to do with the independence of the "processes" themselves.

Could they run in parallel? Or even partially? If it's a yes - then it's already concurrent if it's organized as such. Or it could still just be sequential if that organization hasn't occurred.

So I think of the terminology as a way to frame the independence of parts of a larger process.

Re: Asynchrony is not concurrency

#222

Post by frollogaston »

filleduchaos wrote: post #145
frollogaston wrote: post #136

Earlier quoted context omitted.

Async JS code is parallel too. For example, await Promise.all(...) will wait on multiple functions at once. The JS event loop is only going to interpret one statement at a time, but in the meantime, other parts of the computer (file handles, TCP/IP stack, maybe even GPU/CPU depending on the JS lib) are actually doing things fully in parallel. A more useful distinction would be, the JS interpreter is single-threaded w…

> A more useful distinction would be, the JS interpreter is single-threaded while C code can be multithreaded. ...this seems like a long way round to say "JS code is not parallel while C code can be parallel". Or to put it another way, it seems fairly obvious to me that parallelism is a concept applied to one's own code , not all the code in the computer's universe. Other parts of the computer doing other things has…

But I've never heard of someone caring about their code vs lower-level code running in parallel, just whether or not there are multiple OS threads involved in the end. Like you have 32 CPU cores, your Python batch code is only using 1, and whether or not you use Python threads to fix this depends on if you're using something like Numpy that'll release the GIL.

Re: Asynchrony is not concurrency

#223

Post by Iujia »

Is this interpretation correct?

My original understanding was that asynchrony refers to a behavior — specifically, the non-blocking execution of code.

However, the article defines asynchrony as a capability — the ability to perform non-blocking operations, though it can also execute in a blocking manner depending on the I/O.

The new I/O design decouples the capability from the behavior of whether or not to use it, effectively addressing the function coloring problem.

Re: Asynchrony is not concurrency

#224

Post by laserbeam »

kibwen wrote: post #203
laserbeam wrote: post #117

Earlier quoted context omitted.

I hope this is not a bad answer as I tried to understand what stackless coroutines even are for the past week. 1. Zig plans to annotate the maximum possible stack size of a function call https://github.com/ziglang/zig/issues/23367 . As people say, this would give the compiler enough information to implemented stackless coroutines. I do not understand well enough why that’s the case. 2. Allegedly, this is only possibl…

> As people say, this would give the compiler enough information to implemented stackless coroutines. Stackless coroutines require creating a structure big enough to hold all the locals for the would-be function, but Zig already has that information, along with Rust, and, by definition, every other language that already supports stackless coroutines. The root of that linked issue is that Zig has some desire to static…

As I understand it, you only need to allocate locals in other languages for stackless coroutines because every return statement is a yield point. I think zig is trying a different approach where they can’t get away with that assumption.

Re: Asynchrony is not concurrency

#226

Post by ddingus »

My earlier comment was a mess!

I like the idea of this piece. My trouble with it boils down to getting concurrent and parallel wrong, or mangled somewhat.

Concurrent happens when multiple tasks are happening together. This can be task switching on a single processor, or it can mean they run together on a multiprocessor, or multi core processor.

Secondly, given a sufficiently fast single processor, there is no meaningful difference in concurrency.

Parallel is like concurrent in that multiple tasks are being processed, executed at the same time. What makes parallel different from concurrent is all the tasks are essentially the same, with each of them working on data intended for them to process. Secondly, parallel processing happens on multiprocessors. That is compute systems having multiple cores, each running the task on data made available to a given instance of the task.

Concurrency is a superset of parallel in that all the things that differentiate parallel processing satisfy the requirements needed to call a given compute exercise a concurrent one.

However, concurrency meets other requirements beyond those needed to label ancompute exercise as parallel processing.

I prefer and use the older term, multiprocessor and multiprocessing because "core" can be confusing. In this context they are essentially the same.

I also use the term "sequential compute" to refer to single threaded, single core, non multiprocessing units capable of one threadnof execution.

Asynchrony is a great addition to the topic!

After reading it all again, I submit that Asynchrony is a subset of concurrency, just like parallel is, and it is important enough to warrant an addition to the lexicon, just as parallel is.

However, one matter remains unclear to me as of my writing this:

Does this statement remain true for Asynchrony as it does currently for concurrent, which contains parallel as a specific case?

-->Given a sufficiently fast unprocessed, capable of sequential compute only, a single core, single threaded CPU, there is nobeffectiv3 difference between concurrency done via task switching and concurrency done with multiprocessing.

Is that true for Asynchrony?

I believe it is, and if so, I believe my comment here has a a lot more value than my earlier one.

Great discussion, and Asynchrony is added to my computing lexicon.

Re: Asynchrony is not concurrency

#228

Post by tcfhgj »

sedatk wrote: post #227
tcfhgj wrote: post #197

Earlier quoted context omitted.

why?

Because parent asked for a language feature, not runtime: "One thing that most languages are lacking..."

I haven't linked a runtime but the specific feature, which alleviates manual handling of multiple futures when awaiting multiple futures concurrently, expressed in the language named Rust.
Post reply on HN