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
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.
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.
Task/data parallelism bear to be mentioned because they're common terms; thanks for pointing it out.
I liked the explanations.
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.
