21–29 of 29 posts
I personally prefer to call this asynchronous computing broken into parallel (execute at the same time) and concurrent (execution is interleaved) models.
> The internal vs external distinction also maps to other pairs of concepts like synchronous vs asynchronous, pull vs push, direct vs inverted, opaque vs transparent and local vs remote or distributed. This sentence is superfluous, as none of the listed _pairs_ are mentioned anywhere else ever again, besides sync vs async.
Dichotomous pairs! Sounds simple enough.
Earlier quoted context omitted.
The author admitted to vote-brigading on IRC. Some 50 or so of the votes are from the author's group of upvoting friends and alternate accounts.
That's some fevered imagination.
07:48 HAX
07:48 `slikts: a self post made it to #1
07:48 what kind of witchcraft is this
07:48 xkapastel: just need to get initial traction
07:48 must be nice having a botnet
07:49 tbh :)
...
07:52 `slikts: So *did* you stuff the ballot box with upvotes?
07:52 there's some voting ring
07:52 the first post was a smiley from one of his friends, but afaik people do this sort of thing a lot so it's not really a big deal
07:52 simpson: very slightly
07:53 I don't have anything that could be called a botnet
07:53 but from past experiences it takes just a few votes to get past the initial bump
07:53 too bad, a botnet is a good application of concurrent programming
07:54 also strategic timing counts
07:54 around now is the prime time to share content
07:54 middle of the week when US is getting up
Earlier quoted context omitted.
The main difference between a green and a non-green thread is that the scheduling of said thread is done in userspace. Also, JVM threads are not green since the early 2000s, there's a 1:1 mapping between Java threads and actual kernel threads, and as far as I'm aware, said java threads are never migrated between different kernel threads.
You're right, I qualified it with "classic JVM threads", but a less ancient example would be better; it's just not immediately clear which green thread implementations are also relatively heavyweight like JVM green threads used to be.
Earlier quoted context omitted.
That's some fevered imagination.
Don't lie; it makes you look foolish. 07:48 HAX 07:48 `slikts: a self post made it to #1 07:48 what kind of witchcraft is this 07:48 xkapastel: just need to get initial traction 07:48 must be nice having a botnet 07:49 tbh :) ... 07:52 `slikts: So *did* you stuff the ballot box with upvotes? 07:52 there's some voting ring 07:52 the first post was a smiley from one of his friends, but afaik people do this sort of thin…
Earlier quoted context omitted.
You're right, I qualified it with "classic JVM threads", but a less ancient example would be better; it's just not immediately clear which green thread implementations are also relatively heavyweight like JVM green threads used to be.
I believe the distinction between heavyweight and green threads here is not really the correct comparison. It's more of a comparison between kernel managed (non-green) threads and userspace managed (green) threads. One could argue that Goroutines are green threads that are executed on non-green threads. It's also not infeasible to imagine a system where kernel threads are actually lightweight - single address-space u…
I personally prefer to call this asynchronous computing broken into parallel (execute at the same time) and concurrent (execution is interleaved) models.
Asynchronicity is just how sequential models are extended to support concurrency. Parallelism and concurrency are orthogonal, so a concurrent model can be executed in parallel.
Asynchronicity just means not existing or occurring at the same time, i.e. not synchronised or without synchronisation.
How you expand that definition to computer science is a matter of opinion. I personally take the opinion that an asynchronous operation could be either concurrent or parallel.
> Parallelism and concurrency are orthogonal, so a concurrent model can be executed in parallel.
Completely agree with that.
I tried to make something similar, but more visual, specifically for Python (draft)[1]. Composability is what matters here, when you start to combine these par/async things into big programs, it can become a mess to reason about. [1] https://github.com/ptytb/pyroboros/blob/master/Pyroboros.pdf
That looks nice, but Python is an odd choice for studying synchronization primitives considering it has the GIL.