Thread

Book review: Is parallel programming hard, and, if so, what can you do about it?

149 points · 66 comments · ahelwer

criddell · 1790278663 · focus · HN ↗
This review seems to equate parallelism and concurrency as the same thing and they are not.
As I understand it, the parallelism is about task execution and concurrency is about task structure. Or, as Rob Pike said:
"Concurrency is about dealing with lots of things at once. Parallelism is about doing lots of things at once."
He said that in his Concurrency is not Parallelism talk.
1. ahelwer · 1790279929 · focus · HN ↗
  That battle has unfortunately been lost and different sources give different definitions, often exactly swapped. This was discussed in one of the HN posts linked in the article: <a href="https://news.ycombinator.com/item?id=36318280">https://news.ycombinator.com/item?id=36318280
  In the end I don't think it is too much of an issue. What confusion is really brought by conflating parallelism and concurrency? Sure, concurrent programs can be serialized onto a single core (that's how deterministic simulation testing implementations like Antithesis and record & replay implementations like Mozilla's rr operate). But there isn't some deep conceptual unlock you get by having a strict conceptual boundary between concurrency and parallelism.
  1. jerf · 1790282523 · focus · HN ↗
    Personally I think it's not a good idea to think too rigidly about and try to draw a huge distinction between the two. They're on a continuum and sometimes I'd say some things aren't even strictly speaking "between" them either. Sitting down and trying to classify code into "parallel" and "concurrent" is as likely to do harm as to do any good.
    packetlost · 1790307412 · focus · HN ↗
    I firmly disagree, they are not a continuum, they are binary properties of what they describe. Code can have concurrency primitives, but parallelism primitives must necessarily come from the environment the code executes in, whether it's multiple code streams on a multicore processor or process parallelism provided by an operating system. Programs that are parallel are necessarily also concurrent (if they must communicate between parallel executions), but the inverse is not necessarily true.
    If this distinction wasn't important, Python's infamous GIL would not be an issue.
    kccqzy · 1790364940 · focus · HN ↗
    I completely agree. Even in classic Python with GIL, the programmer would still have to understand concepts from concurrent programming. The asyncio package has to provide types such as Lock, Condition, Semaphore, even when it uses just one thread. The threading package on the other hand uses OS threads, and yet it provides its own version of types such as Lock, Condition, Semaphore, even if it is protected by the Python GIL. The GIL is preventing meaningful parallelism in Python, but it remains the programmer’s responsibility to use concurrency tools correctly.

Open on Hacker News to reply ↗

Unofficial Hacker News client; not affiliated with Y Combinator.