Dichotomous pairs! Sounds simple enough.
Concurrency Glossary
11–20 of 29 posts
Re: Concurrency Glossary
#12Woah! 112 points and no comments. Has anybody actually read it? Or is everyone upvoting in hopes that someone knowledgeable will comment about the quality of the content?
It's mostly unstructured set of unrelated concepts. I have no idea why people would upvote that.
I know most of these concepts and the valuable part was to fill the gaps what I've missed. I would also like to read about work-stealing threadpools in a similar manner.
I liked the explanations.
Re: Concurrency Glossary
#13Nice resource! It explains the difference between parallelism and concurrency quite clearly. Some things can be improved though: > The difference between green and lightweight threads is that green threads aren't necessarily lightweight; an example of green threads is classic Java Virtual Machine threads, while Go goroutines are an example of lightweight threads. Saying that the difference between green and lightweig…
Thanks, and yeah, the part about lightweight threads stands to be expanded. Other missing parts are reactive vs interactive, linearizable vs serializable and push vs pull.
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.
Re: Concurrency Glossary
#14> 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.
Re: Concurrency Glossary
#15I personally prefer to call this asynchronous computing broken into parallel (execute at the same time) and concurrent (execution is interleaved) models.
Re: Concurrency Glossary
#16Woah! 112 points and no comments. Has anybody actually read it? Or is everyone upvoting in hopes that someone knowledgeable will comment about the quality of the content?
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.
Re: Concurrency Glossary
#17I found only one occurrence of the word task in the document. The entire paradigm of task parallelism is omitted. The style is heavy. I consider myself skilled in the area but struggled to map wording to my conceptual framework or experience. For a novice, most of the text is probably totally impenetrable. As an example: > Locking can have coarse- or fine-grained synchronization granularity, where coarse-grained gran…
The trade-offs of locks are accidental locking like deadlocks; message passing removes this trade-off but is less flexible, and dataflow further constrains the use of explicit synchronization. It's part of the larger argument for declarative approaches enabling equational reasoning.
Task/data parallelism bear to be mentioned because they're common terms; thanks for pointing it out.
Re: Concurrency Glossary
#18Woah! 112 points and no comments. Has anybody actually read it? Or is everyone upvoting in hopes that someone knowledgeable will comment about the quality of the content?
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.
Re: Concurrency Glossary
#19Earlier quoted context omitted.
Thanks, and yeah, the part about lightweight threads stands to be expanded. Other missing parts are reactive vs interactive, linearizable vs serializable and push vs pull.
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.
Re: Concurrency Glossary
#20I 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.