Re: Is Parallel Programming Hard, And, If So, What Can You Do About It?

On Wed, 21 May 2025 15:30:43 -0400, Stefan Monnier wrote:

In the case of concurrency the core question is: Given a set of somewhat
independent tasks working on some chunks of data, make sure the computed
result is correct, e.g. design tools like mutexes, memory barriers,
transactional memory, static analysis, reasoning principles, etc...
whose core focus is on making sure there's no race conditions, dead
locks, ...
 
In the case of parallelism, the core question instead is: given a
program/algorithm, restructure (or even completely replace) it so as to
divide it into somewhat independent tasks that can take advantage of
multiple CPUs to finish the work faster.

All those issues of race conditions, deadlocks, livelocks etc apply
equally whether the concurrency/parallelism is real (multiple physical
CPUs) or virtual (process preemption on shared CPUs).

The difference is that different bugs in the synchronization/locking show
up in different situations. This is why it is helpful to test your
concurrent code in a variety of situations.