Concurrency Glossary
slikts.github.io
Concurrency Glossary
1–10 of 29 posts
Re: Concurrency Glossary
#2Skaisti :)
Re: Concurrency Glossary
#3Woah! 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?
Re: Concurrency Glossary
#4Woah! 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.
Re: Concurrency Glossary
#5Woah! 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?
For what it's worth, the feedback I've had so far elsewhere suggests that there aren't particular inaccuracies. A somewhat contentious part is defining concurrency in terms of order independence, but the main source for that is Peter Van Roy (https://www.info.ucl.ac.be/~pvr/VanRoyChapter.pdf section 4.3), so it's of good provenance.
Re: Concurrency Glossary
#6Woah! 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.
The relations could definitely be made more clear, but if you could point out what specific terms you find unrelated, I could explain how they fit together. The basic organization is working up the ladder of abstraction; for example, scheduling is a fundamental concept, so it comes before other concepts that rely on it (which is all of them).
Re: Concurrency Glossary
#7Nice 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 lightweight is that green aren't necessarily lightweight isn't helpful. Some explanation on what they are and when they differ would be useful.
Re: Concurrency Glossary
#8Nice 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.
Re: Concurrency Glossary
#9I 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
Re: Concurrency Glossary
#10I 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 granularity trades concurrency for deterministic execution while fine-grained granularity is more concurrent but less predictable.
That's a property of the program (or the programmer), not locking as such. Fine-grained locking is of course as reliable and predictable as coarse-grained but when an operation involves multiple updates that must appear as atomic (a transactional guarantee, f.e.), coarse-grained locking is straightforward and fine-grained locking is more difficult to get right. There is no way, however, the programmer should accept possibly incorrect updates on the basis that now the program runs faster.
> Declarative concurrency models reduce the need to make trade-offs between concurrency and correctness ...
Now that's a huge statement. How can that trade-off be justified in the first place (it can be!)? Do we really have a need and accept that trade-off with fine-grained locking above?
I would not insist my interpretation is right but that's exactly my point.