[omazurov]

I 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.

[slikts]

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.