Yet another blog post about how parallelism is not concurrency | Hacker News Reader

Yet another blog post about how parallelism is not concurrency

composition.al

38 pointsdbaupp7 comments

I like this article especially because it doesn't take sides, unlike many others. Concurrency is not "better" than parallelism, and parallelism is not "better" than concurrency. Sometimes you want concurrency because you want to interleave operations, and sometimes you want parallelism because you want stuff to go faster, and sometimes you want both.

For me, these drawings made it quite clear what the differences were:

http://joearms.github.io/2013/04/05/concurrent-and-parallel-...

It's more complicated than that, but the pic could be a decent starting point. Concurrency is the person waiting in the line pulling out their cell phone and checking their email while they're waiting for their turn at the coffee machine. The get_coffee thread is scheduled, but blocked, so the person waiting is handling the check_email thread. They can only do one thing at a time, but that one thing can swap in and out as situations change.

That example is not correct, a key concept in concurrency is that it gives way to potential parallelism, but this does not follow from the queues and coffee machines analogy.

> ...a key concept in concurrency is that it gives way to potential parallelism, but this does not follow from the queues and coffee machines analogy.

How do you figure? From TFA:

> A lot of software systems are useful to reason about as having multiple threads of control — for instance, separate clients connecting to a server, or separate UI widgets. Programs that are organized this way exhibit concurrency. The fact that multiple threads of control are a good way of organizing and reasoning about certain programs is orthogonal to whether those programs are running on one processor core or four or 1000.

One queue of people executing the "get espresso from the coffee machine" routine and another queue executing the "get drip coffee from the coffee machine" routine seems like concurrency to me. Two different routines are competing for the use of a single resource, but neither routine needs to know about the other -if we presume that there's a work scheduling system in place-.

What's more, this trivially gives way to parallelism: add another coffee machine (which is analogous to another CPU core) and assign one of the queues to that machine. BAM! Instant parallelism.

What am I misunderstanding here?

concurrency: pretending to do multiple things at the same time

parallelism: actually doing multiple things at the same time

Mostly, the distinction is useful if you want to paper over slow I/O without making sure your algorithms can actually run efficiently spread over multiple cores.

Concurrency isn't pretending to do multiple things at the same time, it's the concept of multiple things happening at once.

Concurrency doesn't necessarily involve parallel computation. Concurrency is just when you think about something as multiple things happening at once. This includes parallel computation, as well as premptive multitasking on a single CPU, as well as cooperative multitasking (including in green threads). It also includes coroutines, and the notion of an "iterator". Arguably dealing with time is also concurrency because it weave your program's thread of execution with the thread of time.

Reply on news.ycombinator.com