Concurrency vs Parallelism
debt(d7/e5/b7/t7)
Closest to 'only careful code review or runtime testing' (d7). The term's detection_hints show automated: no — there's no static tool that can detect whether you've confused concurrency with parallelism. You discover the mistake through performance profiling, load testing, or careful architectural review. The choice manifests as 'async doesn't speed up my CPU-bound task' which only surfaces under realistic production load.
Closest to 'touches multiple files / significant refactor in one component' (e5). The quick_fix indicates a conceptual shift (I/O-bound → async, CPU-bound → parallelism), but implementing this typically means refactoring how work is dispatched. Changing from async coroutines to worker processes or queue-based parallel jobs affects job dispatching, result collection, and error handling — a significant but localised architectural change.
Closest to 'strong gravitational pull' (b7). The applies_to shows this spans web, cli, and queue-worker contexts — the decision shapes how your entire application handles workload. Choosing the wrong model (async for CPU-bound, or sequential for I/O-bound) creates persistent drag: every performance optimization attempt must work around the fundamental mismatch. Not quite b9 because you can carve out subsystems that use the correct model.
Closest to 'serious trap' (t7). The misconception explicitly states developers conflate concurrency and parallelism as 'the same thing.' This contradicts how similar concepts work elsewhere — in languages like Go or Node.js, the distinction is more visible. The common_mistakes reinforce this: developers assume async gives parallelism, or that multi-process automatically means parallel execution regardless of CPU cores. A competent developer from single-threaded backgrounds will guess wrong.
TL;DR
Explanation
Concurrency: multiple tasks make progress over time, potentially interleaved on one core. Parallelism: tasks execute at the exact same instant on multiple cores/machines. PHP FPM: parallelism (multiple processes on multiple cores) but no shared memory concurrency within a request. Node.js: concurrency (event loop) but single-threaded (no parallelism except worker_threads). Go: both — goroutines for concurrency, GOMAXPROCS for parallelism. CPU-bound tasks need parallelism. I/O-bound tasks benefit from concurrency (async). Rob Pike: 'Concurrency is about structure, parallelism is about execution.'
Common Misconception
Why It Matters
Common Mistakes
- Using async for CPU-bound tasks — async adds overhead without true parallelism.
- Assuming multi-process = parallelism — it is, but also requires multiple CPU cores.
- Not knowing PHP-FPM is parallel (multiple processes) but each request is sequential.
Code Examples
// Async for CPU-bound (wrong tool):
async function compressImage(img) {
await heavyCpuCompression(img); // Blocks event loop — should use Worker
}// Node: Worker for CPU-bound:
const { Worker } = require('worker_threads');
new Worker('./compress.js', { workerData: img });
// PHP: FPM workers ARE parallel (multiple processes)
// For async I/O: Swoole coroutines
// For CPU: pcntl_fork or queue + multiple worker processes