That's a useful interpretation of the two terms, but it's far from universal and the two have often been used fairly interchangeably over the decades. It's been much more useful as a distinction when someone discussing it announces that that is how they're separating the two concepts, instead of trying to force other people to adopt that particular pair of definitions.
Frankly the software industry suffers heavily from a lack in standardized terminology. The precise definition of parallelism vs concurrency is one that I think is incredibly important. You are doing your peers a disservice by using them interchangeably, they are not.
You can have parallelism without much concurrency. Think parsing a bunch of files, where you have a `fn parse(path) -> AST` which does not rely on global state. Parallelizing something like this is trivial, with no mutexes in sight, and can be great for performance in many situations.
On the other hand, you can have concurrency without parallelism. Think a database where IO is the bottleneck, and you have multiple clients doing reading and writing at all once, potentially to the same table, in isolated transactions, on different db nodes which have to communicate. That's a lot of concurrency and nasty locks, even if you're running on a single core and wouldn't get much of a speedup from doing otherwise.
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: 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.
I think there is a deep conceptual unlock: concurrency is about semantics, whilst parallelism is an operational property. I use this distinction a lot in my own work. Concurrent programming primitives are inherently non-deterministic (and usually about handling non-deterministic events), on top of which we must then establish some kind of properties (sometimes determinism to some extent). Many interesting parallel operations are however completely deterministic, and the fact that they are parallel is a property of their assigned cost model (and hopefully implementation, in practice).
I agree that this distinction is hardly universal, but it seems to be growing increasingly established, and I think it is worth fighting for it.
I don't like the essential characteristic of concurrency being nondeterminism. its really that multiple processes are running concurrently. if we don't have serializing operations, we have arbitrary execution order. but if we do then we can introduce the necessary determinism while still being (largely) concurrent in evaluation. and if those logically concurrent processes are physically concurrent then we have parallelism. so the first is necessary but not sufficient for the latter.
so I find saying that we have one or the other to pretty misleading.
Im not saying arrival order isn't a key consequence of concurrency in many cases, it's just not the same as concurrency itself. I guess the point for me is that when we're programming or when we're using models, we define the partial ordering. so if an event arrives from outside and causes a message to be put in the queue, the read of that event by another thread is still after the external event.
so our job is really to kind of look at all the possible topological sorts of that 'after' ordering, and ensure that they are all correct, and if not, add additional edges by using locks or whatever mechanism.
kind of more interested are techniques like mvcc and crdt, which make _any_ causal ordering of events (topo sort) result in a meaningful answer.
but if you look at classical simd for example, we have concurrency (and parallelism) without additional constraints, because the threads are strongly synchronized at the hardware level.
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.
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.
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.
It's really important to get people to recognize that concurrency can happen on a single core or a single task-switching thread. You don't necessarily need to split off parallelism to explain that, but it helps.
And it's worth talking about how you can have a single task run in a parallel way, for varying strictness of 'single'.
Coroutines and SIMD are far enough apart that their execution models should have different words.
As other comments have pointed out, this is just not true in general usage.
When I was a grad student studying this stuff (~20 years ago), we used "parallelism" to mean running on different cores at the same time and "concurrency" to mean preemptive multithreading on a single processor.
Parallelism without concurrency is useless, and concurrency without parallelism is usually cooperative and does not have the same challenges. So in essence, the title is correct.
> concurrency without parallelism is usually cooperative
preemptive concurrency is almost as old as interactive computers. Until fairly recently, most computers were single core, but you wouldn't have wanted to use a cooperatively scheduled OS [1], especially on a multiuser machine.
[1] yes, in the '80s some popular microcomputer OSs were single threaded (DOS) or cooperatively scheduled (classic macos and 16bit windows), but even then preemptive OSs were available (amigados).
Yeah although they say something like nodejs is not parallel but concurrent it’s not technically true from a systems standpoint. There are actually tons of operations happening at the same time. It’s just all delegated to IO.
True concurrency that is absolutely absent of parallelism is a bit pointless, that’s why although node is concurrent, it is explicitly designed such that it migrates parallelism to IO.
I disagree. You don't need concurrency. Say for a video game with many things happening all at once. You think you need concurrency... but you don't.
Imagine for the simplest example of a CPU only based game. If I want to render the positions of thousands of soldiers, just do it in a loop. Why would I spawn thousands of coroutines ONLY for the coroutines to do it all in order anyway? Makes no sense.
The 2 terms have been used inconsistently in the past and some authors have even alternated between them during their lifetime.
I prefer the view where "concurrent" processes (a.k.a. tasks a.k.a. threads) are those where the execution of their parts is done in an unpredictable order, i.e. they can be interleaved in an unpredictable order.
For the correctness of programs, it only matters whether some things are executed sequentially or concurrently. If they are executed concurrently, whichever order of execution happens must not change the results in any way.
For correctness, it does not matter whether in reality all the concurrent processes are executed by a single hardware thread, so none of them are ever executed simultaneously in time, or all the processes are executed in parallel, on different processor cores.
For correct concurrent programming, what matters is how the access to shared resources is controlled, using either mutual exclusion, or optimistic accesses with retries when necessary, or dynamic partitioning of the shared resource (i.e. of an array or of a queue) into disjoint parts that allow concurrent accesses.
Parallelism only matters for the achievable performance of a program. To enable parallel execution for increased performance, there are also specific programming techniques that are required, for minimizing the dependencies that force serial execution, i.e. data dependencies a.k.a. functional dependencies, flow-of-control dependencies and resource dependencies a.k.a. operational dependencies.
Something that can cause confusions between concurrency and parallelism is the difference between the program written by the programmer and how it is really executed by a modern CPU.
When the programmer writes a program that describes multiple concurrent processes, a CPU may easily execute all of them in parallel. But even when the programmer writes only a sequential program, a modern CPU with out-of-order execution will analyze the program, identify the dependencies between instructions and convert the sequential program into a set of concurrent processes that will be executed in parallel by separate hardware execution units, if possible, though they may also be executed sequentially on a single execution unit, when the others are busy.
Thus even when the programmer does not write a concurrent program, it may still have parts that are executed in parallel, but that is not parallelism without concurrency, the concurrency is introduced by the hardware scheduler, which identifies shared resources and any other dependencies that could inhibit the transformation of the sequential program into a concurrent program.
I would probably recommend the art of multiprocessor programming (herlihy and shavitz) as a good starting point for concurrent programming. There is also " A primer on memory consistency and cache coherence" (Nagarajan et al) if you want to get more into the interaction between memory consistency and coherence.
The Raku language (formerly Perl 6) and its underlying VM has features to support parallel programming, concurrency and asynchrony, designed to make common cases relatively easy to code and avoid pitfalls.
Jonathan Worthington, the author of the VM and these features, has given an excellent presentation on the concepts and their implementation.
What kind of tooling were you using? IMO, deadlocks are some of the easiest concurrency bugs to diagnose. If you can see the thread stacks, it is easy to see threads are blocked from acquiring a lock. If you can attach a debugger, it is easy to see which locks are involved. Then you can pretty much figure things out using the straightforward guideline that if multiple locks are involved, they must be acquired in the same order in all code paths.
I don't want to devalue your experience, but I am surprised to hear that. Livelock is harder to debug. Silent data corruption caused by missing or wrong synchronization is way harder to debug.
ah, that's probably a missed wakeup problem! Much nastier. Still seeing where your thread is blocked might hint you to where the missing signal should have been.
So I actually had this exact issue where we suspected a deadlock, but the application was limping along and we couldn't justify attaching a debugger. I managed to confirm my suspicions with judicious use of perf and /proc/<pid>/task/<tid>/wchan .
Just drain the traffic (make the load balancer temporarily not send traffic to it) and attach a debugger. I hope your load balancer has that feature because health checking also needs it.
> Silent data corruption caused by missing or wrong synchronization is way harder to debug.
Reminds me of being a young and ambitious C++ programmer 25 years ago, discovering that when you have a map and do “return m[k]”, it is not, in fact, a read-only operation when k does not exist. After which I learned that const-correctness is not just a nice-to-have, especially in multithreaded applications.
But yeah deadlocks are hardly ever a difficult issue to diagnose. They may potentially be difficult to resolve, but at that point, it very much suggests that there’s an architecture / design issue.
Agree completely. But they become harder when you eschew standard constructs like threads and mutexes and bring-your-own losing nice things like debugger supports and stack traces. Now your logical tasks might be deadlocked, while your threads appear to be running correctly. This is surprisingly common this day with async runtimes and less than stellar debugging support.
Rotary vs fixed wing is more like GPU vs CPU programming. Within each you still need to understand the capabilities of the machine before you can go wide effectively.
Many of the pieces of software which people claim are miserably slow are using one core irresponsibly. Usually because they're operating in a "only one thread can touch the UI" environment and that thread keeps blocking on everything.
Writing concurrent code is fun. The problem is that debugging it feels like trying to catch a ghost that only haunts your system at 3 AM on a Saturday.
My experience has been the opposite. If lean had linear types (or separation types), it would be, but as it is, Lean's just a little bit too focused on talking about results to tidily talk about how those results are computed.
I don't know. For many operations, you can encode "how" by saying "under any permutation of this sequence of applications". At least, for EREW machines.
As I found out recently, there's a lighter option: model checkers like Spin. You describe your synchronization logic in a small modeling language (Promela), and Spin tries every possible interleaving of that model.
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.
That's a useful interpretation of the two terms, but it's far from universal and the two have often been used fairly interchangeably over the decades. It's been much more useful as a distinction when someone discussing it announces that that is how they're separating the two concepts, instead of trying to force other people to adopt that particular pair of definitions.
Frankly the software industry suffers heavily from a lack in standardized terminology. The precise definition of parallelism vs concurrency is one that I think is incredibly important. You are doing your peers a disservice by using them interchangeably, they are not.
You can have parallelism without much concurrency. Think parsing a bunch of files, where you have a `fn parse(path) -> AST` which does not rely on global state. Parallelizing something like this is trivial, with no mutexes in sight, and can be great for performance in many situations.
On the other hand, you can have concurrency without parallelism. Think a database where IO is the bottleneck, and you have multiple clients doing reading and writing at all once, potentially to the same table, in isolated transactions, on different db nodes which have to communicate. That's a lot of concurrency and nasty locks, even if you're running on a single core and wouldn't get much of a speedup from doing otherwise.
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: 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.
I think there is a deep conceptual unlock: concurrency is about semantics, whilst parallelism is an operational property. I use this distinction a lot in my own work. Concurrent programming primitives are inherently non-deterministic (and usually about handling non-deterministic events), on top of which we must then establish some kind of properties (sometimes determinism to some extent). Many interesting parallel operations are however completely deterministic, and the fact that they are parallel is a property of their assigned cost model (and hopefully implementation, in practice).
I agree that this distinction is hardly universal, but it seems to be growing increasingly established, and I think it is worth fighting for it.
I don't like the essential characteristic of concurrency being nondeterminism. its really that multiple processes are running concurrently. if we don't have serializing operations, we have arbitrary execution order. but if we do then we can introduce the necessary determinism while still being (largely) concurrent in evaluation. and if those logically concurrent processes are physically concurrent then we have parallelism. so the first is necessary but not sufficient for the latter.
so I find saying that we have one or the other to pretty misleading.
deterministic scheduling is possible, but most theoretical concurrency models assume non-determinism.
And even with deterministic scheduling, concurrency might be dictated by external stimuli (for example request arrival) that are not deterministic.
Im not saying arrival order isn't a key consequence of concurrency in many cases, it's just not the same as concurrency itself. I guess the point for me is that when we're programming or when we're using models, we define the partial ordering. so if an event arrives from outside and causes a message to be put in the queue, the read of that event by another thread is still after the external event.
so our job is really to kind of look at all the possible topological sorts of that 'after' ordering, and ensure that they are all correct, and if not, add additional edges by using locks or whatever mechanism.
kind of more interested are techniques like mvcc and crdt, which make _any_ causal ordering of events (topo sort) result in a meaningful answer.
but if you look at classical simd for example, we have concurrency (and parallelism) without additional constraints, because the threads are strongly synchronized at the hardware level.
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.
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.
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.
It's really important to get people to recognize that concurrency can happen on a single core or a single task-switching thread. You don't necessarily need to split off parallelism to explain that, but it helps.
And it's worth talking about how you can have a single task run in a parallel way, for varying strictness of 'single'.
Coroutines and SIMD are far enough apart that their execution models should have different words.
As other comments have pointed out, this is just not true in general usage.
When I was a grad student studying this stuff (~20 years ago), we used "parallelism" to mean running on different cores at the same time and "concurrency" to mean preemptive multithreading on a single processor.
That's the same distinction, made in the same way, isn't it?
Pretty much, yes.
Well, we were using it to talk about things like cache invalidation and lax memory models rather than properties of algorithms.
With the rise of async there is once again lots of cooperative multitasking being used, not just preemptive multithreading
But that's the only nit
Parallelism without concurrency is useless, and concurrency without parallelism is usually cooperative and does not have the same challenges. So in essence, the title is correct.
> concurrency without parallelism is usually cooperative
preemptive concurrency is almost as old as interactive computers. Until fairly recently, most computers were single core, but you wouldn't have wanted to use a cooperatively scheduled OS [1], especially on a multiuser machine.
[1] yes, in the '80s some popular microcomputer OSs were single threaded (DOS) or cooperatively scheduled (classic macos and 16bit windows), but even then preemptive OSs were available (amigados).
Right, I forgot about multithreading on one core.
> Parallelism without concurrency is useless
SIMD is parallelism without concurrency.
in the English vernacular when you deal with something you do something.
Yeah although they say something like nodejs is not parallel but concurrent it’s not technically true from a systems standpoint. There are actually tons of operations happening at the same time. It’s just all delegated to IO.
True concurrency that is absolutely absent of parallelism is a bit pointless, that’s why although node is concurrent, it is explicitly designed such that it migrates parallelism to IO.
> True concurrency that is absolutely absent of parallelism is a bit pointless
It is very important in interactive or realtime systems.
I disagree. You don't need concurrency. Say for a video game with many things happening all at once. You think you need concurrency... but you don't.
Imagine for the simplest example of a CPU only based game. If I want to render the positions of thousands of soldiers, just do it in a loop. Why would I spawn thousands of coroutines ONLY for the coroutines to do it all in order anyway? Makes no sense.
The 2 terms have been used inconsistently in the past and some authors have even alternated between them during their lifetime.
I prefer the view where "concurrent" processes (a.k.a. tasks a.k.a. threads) are those where the execution of their parts is done in an unpredictable order, i.e. they can be interleaved in an unpredictable order.
For the correctness of programs, it only matters whether some things are executed sequentially or concurrently. If they are executed concurrently, whichever order of execution happens must not change the results in any way.
For correctness, it does not matter whether in reality all the concurrent processes are executed by a single hardware thread, so none of them are ever executed simultaneously in time, or all the processes are executed in parallel, on different processor cores.
For correct concurrent programming, what matters is how the access to shared resources is controlled, using either mutual exclusion, or optimistic accesses with retries when necessary, or dynamic partitioning of the shared resource (i.e. of an array or of a queue) into disjoint parts that allow concurrent accesses.
Parallelism only matters for the achievable performance of a program. To enable parallel execution for increased performance, there are also specific programming techniques that are required, for minimizing the dependencies that force serial execution, i.e. data dependencies a.k.a. functional dependencies, flow-of-control dependencies and resource dependencies a.k.a. operational dependencies.
Something that can cause confusions between concurrency and parallelism is the difference between the program written by the programmer and how it is really executed by a modern CPU.
When the programmer writes a program that describes multiple concurrent processes, a CPU may easily execute all of them in parallel. But even when the programmer writes only a sequential program, a modern CPU with out-of-order execution will analyze the program, identify the dependencies between instructions and convert the sequential program into a set of concurrent processes that will be executed in parallel by separate hardware execution units, if possible, though they may also be executed sequentially on a single execution unit, when the others are busy.
Thus even when the programmer does not write a concurrent program, it may still have parts that are executed in parallel, but that is not parallelism without concurrency, the concurrency is introduced by the hardware scheduler, which identifies shared resources and any other dependencies that could inhibit the transformation of the sequential program into a concurrent program.
I would probably recommend the art of multiprocessor programming (herlihy and shavitz) as a good starting point for concurrent programming. There is also " A primer on memory consistency and cache coherence" (Nagarajan et al) if you want to get more into the interaction between memory consistency and coherence.
I can recommend "Shared Memory Synchronization," by Michael L. Scott for an introduction to nuts-and-bolts level detail.
The Raku language (formerly Perl 6) and its underlying VM has features to support parallel programming, concurrency and asynchrony, designed to make common cases relatively easy to code and avoid pitfalls.
Jonathan Worthington, the author of the VM and these features, has given an excellent presentation on the concepts and their implementation.
https://www.youtube.com/watch?v=JpqnNCx7wVY
Should have been titled "Is Parallel Programming What Can You Hard, And, If So, Do About It?"
world! hello
I do agree with your comment.
not not
Don't dead, open inside.
The plural of a mutex is "deadlock"
Spent days tracking down a deadlock that only manifested under specific load. Definitely hard, even with good tooling.
What kind of tooling were you using? IMO, deadlocks are some of the easiest concurrency bugs to diagnose. If you can see the thread stacks, it is easy to see threads are blocked from acquiring a lock. If you can attach a debugger, it is easy to see which locks are involved. Then you can pretty much figure things out using the straightforward guideline that if multiple locks are involved, they must be acquired in the same order in all code paths.
I don't want to devalue your experience, but I am surprised to hear that. Livelock is harder to debug. Silent data corruption caused by missing or wrong synchronization is way harder to debug.
They are, if you can attach a debugger. If only one thread is stuck and in production... Not so much (but there are still much harder bugs).
ah, that's probably a missed wakeup problem! Much nastier. Still seeing where your thread is blocked might hint you to where the missing signal should have been.
I didn't mean literally a single thread, just that not the whole application is hang.
So I actually had this exact issue where we suspected a deadlock, but the application was limping along and we couldn't justify attaching a debugger. I managed to confirm my suspicions with judicious use of perf and /proc/<pid>/task/<tid>/wchan .
Just drain the traffic (make the load balancer temporarily not send traffic to it) and attach a debugger. I hope your load balancer has that feature because health checking also needs it.
> Silent data corruption caused by missing or wrong synchronization is way harder to debug.
Reminds me of being a young and ambitious C++ programmer 25 years ago, discovering that when you have a map and do “return m[k]”, it is not, in fact, a read-only operation when k does not exist. After which I learned that const-correctness is not just a nice-to-have, especially in multithreaded applications.
But yeah deadlocks are hardly ever a difficult issue to diagnose. They may potentially be difficult to resolve, but at that point, it very much suggests that there’s an architecture / design issue.
Agree completely. But they become harder when you eschew standard constructs like threads and mutexes and bring-your-own losing nice things like debugger supports and stack traces. Now your logical tasks might be deadlocked, while your threads appear to be running correctly. This is surprisingly common this day with async runtimes and less than stellar debugging support.
We should make developers prove they can use one core responsibility before we hand them 64.
Much like we get pilots comfortable in single engine aircraft before we have them fly around in 747s and AC130s.
They're fundamentally different skills in my view. It's helicoptors vs fixed wing, rather than single engine vs multi engine
Rotary vs fixed wing is more like GPU vs CPU programming. Within each you still need to understand the capabilities of the machine before you can go wide effectively.
Many of the pieces of software which people claim are miserably slow are using one core irresponsibly. Usually because they're operating in a "only one thread can touch the UI" environment and that thread keeps blocking on everything.
Nothing beats serial programming imo
Writing concurrent code is fun. The problem is that debugging it feels like trying to catch a ghost that only haunts your system at 3 AM on a Saturday.
Debugging race conditions feels like chasing ghosts; often makes me just reach for a message queue.
... until you realize you can have race conditions with queues as as well.
Nope! Parallel programming is all yahoo, wee, look at that go!
Then comes the parallel debugging.
Pretty soon it's 15 years later, different person, yahoo-wee bro having long moved on.
Give each dev their own core.
Parallel programming is a great application for LLM correctness proofs in Lean.
You can't unit test your way out, but if you care about the code's correctness, today there's a way.
Mix of different types of tests helps.
Best examples are SQLite and Jepsen test suites for dbms engines.
https://jepsen.io/
My experience has been the opposite. If lean had linear types (or separation types), it would be, but as it is, Lean's just a little bit too focused on talking about results to tidily talk about how those results are computed.
I don't know. For many operations, you can encode "how" by saying "under any permutation of this sequence of applications". At least, for EREW machines.
As I found out recently, there's a lighter option: model checkers like Spin. You describe your synchronization logic in a small modeling language (Promela), and Spin tries every possible interleaving of that model.
I remember a music producer dreaming of a keyboard player with just one finger.
Even though I'm not a programmer I really enjoyed reading this book review.
What can you do about it?
Ask Claude, which has read all the existing literature on parallel programming, to make the program faster.