Hacker News new | ask | show | jobs
by shoo 2878 days ago
quoting the article:

> Concurrency is like having two threads running on a single core CPU.

> Parallelism is like having two threads running simultaneously on different cores

> It is important to note that parallelism implies concurrency but not the other way round.

Aurgh! I don't think this attempted definition-by-simile is helpful, or even somewhat correct.

I much prefer yosefk's way of framing things:

> > concurrent (noun): Archaic. a rival or competitor.

> > Two lines that do not intersect are called parallel lines.

...

> Computation vs event handling

> With event handling systems such as vending machines, telephony, web servers and banks, concurrency is inherent to the problem – you must resolve inevitable conflicts between unpredictable requests. Parallelism is a part of the solution - it speeds things up, but the root of the problem is concurrency.

> With computational systems such as gift boxes, graphics, computer vision and scientific computing, concurrency is not a part of the problem – you compute an output from inputs known in advance, without any external events. Parallelism is where the problems start – it speeds things up, but it can introduce bugs.

...

> concurrency is dealing with inevitable timing-related conflicts, parallelism is avoiding unnecessary conflicts

yosefk's whole essay about this is great: https://yosefk.com/blog/parallelism-and-concurrency-need-dif...

2 comments

I also initially thought the same thing. Page two of "Parallel and Concurrent programming in Haskell" maybe says it in a nicer way:

>A parallel program is one that uses a multiplicity of computational hardware ....

>concurrency is a program-structuring technique in which there are multiple threads of control...

(a pdf can readily be found with your favorite search engine for the full extract :) ).

I would much prefer to see a precise, rigorous definition and then examples (or eg and then defn is also acceptable), instead of just a list of examples. Examples help you understand a rigorous statement. But, if you only give a hand waving explanation for something, I think it just creates more confusion in the end, as you never know exactly what is correct. It's leaving it open for ambiguity.

Also a big fan of this "Visualizing Concurrency in Go": http://divan.github.io/posts/go_concurrency_visualize/