Concurrency Comparisons
Side-by-side trade-offs where neither column wins. The workload, the runtime and how much correctness risk you can carry decide — and each comparison ends with the verdict that follows from that, not from a preference.
Concurrency vs parallelismThreads vs processesAsync vs threadsEvent loop vs thread poolMutex vs semaphoreOptimistic vs pessimistic concurrency controlLock-based vs lock-freeBounded vs unbounded queue
Concurrency vs parallelism
The distinction the whole domain rests on. One is about structure — several things in progress at once. The other is about execution — several things running at the same instant. A system can have either, both or neither, and choosing the wrong one is how you end up with a thread pool that does not help.
| Dimension | Concurrency | Parallelism |
|---|---|---|
| What it means | Several units of work are in progress over the same period | Several units of work execute at the same instant |
| Needs multiple cores | No — one core interleaving is enough | Yes, by definition |
| What it buys | Overlap of waiting; responsiveness; better use of one core | Reduced wall-clock time for computation |
| Helps I/O-bound work | Yes — this is the whole point | Only incidentally |
| Helps CPU-bound work | No — the same total CPU, interleaved | Yes, up to the serial fraction |
| Typical mechanism | Event loop, coroutines, async/await, one thread | Threads on separate cores, processes, SIMD, GPU |
| Main failure | A CPU-bound step blocks everything else | Coordination overhead exceeds the work saved |
| Correctness burden | Interleavings at every suspension point | Interleavings at every instruction, plus memory visibility |
Use Concurrency when
- The work is dominated by waiting: network, disk, other services.
- You need the system to stay responsive while something slow is in progress.
- Thousands of units of work, each cheap, each mostly idle.
Use Parallelism when
- The work is dominated by computation and the parts are independent.
- Wall-clock time is the objective and you have cores that are idle.
- The work per chunk is large enough to pay for splitting and merging.
Verdict
Classify the work first. Waiting-bound work wants concurrency, and adding cores to it changes nothing. Compute-bound work wants parallelism, and adding async to it changes nothing except the number of places a bug can hide.