Concurrency & Parallelism

Should this work overlap, run simultaneously, or neither?

The distinction the whole domain rests on: overlapping progress versus simultaneous execution, why each exists, how to classify work as waiting-bound or compute-bound, and the honest admission that concurrency is always bought with complexity.

What unit actually carries this work, and who schedules it?

Processes, threads, tasks and coroutines as distinct things a runtime can hand you — and the language-specific reality of what each one buys in C++, JavaScript and CPython. The kernel-side mechanics live in Operating Systems.

What does suspending a task actually do, and what still runs?

Async/await as an execution model rather than syntax: futures and promises, the event loop, worker threads and web workers, and the two lessons that matter most — async is not parallelism, and a CPU-bound handler stalls the loop for everyone.

What is shared, what must stay true, and which schedule breaks it?

The core of the domain. Shared mutable state, invariants, finding the minimal critical section, enumerating interleavings to locate a failing schedule, and the distinction between a race condition and a data race that most engineers conflate.

Which guarantee does this primitive give, and which does it not?

Mutexes and the scope you put them around, read/write locks, semaphores as permit counters, condition variables and the predicate loop — with lost and spurious wakeups as the failures that follow from getting the loop wrong.

Can we avoid sharing state by moving data instead?

Producer/consumer as the flagship pattern, bounded versus unbounded queues, backpressure as the conversation between a fast producer and a slow consumer, channels, message passing and the actor model — coordination without shared memory.

How does a correct-looking system stop making progress?

The four conditions for deadlock and how to break each one, lock ordering as the practical answer, wait-for graphs and their cycles, livelock where everyone is busy and nothing advances, starvation, fairness and priority inversion.

Why did adding threads make it slower?

Eight cores all waiting on one lock. Convoys, false parallelism, oversubscription, the real cost of a context switch, and busy waiting — the module that explains why parallel hardware does not imply parallel throughput.

What does an atomic operation actually make indivisible?

Atomic reads, writes and compare-and-swap, why an atomic variable does not make a multi-step invariant safe, and lock-free concepts treated honestly as progress guarantees rather than performance promises — CAS loops, the ABA problem, wait-free versus lock-free.

Will the other thread even see what I wrote?

The advanced core: threads do not necessarily observe memory operations in source order. Happens-before, compiler and CPU reordering, barriers, false sharing, cache coherence traffic, safe publication and why double-checked locking is the canonical cautionary tale.

How many workers, and what happens to the work that does not fit?

Pools as bounded resource use rather than unlimited spawning, the reasoning behind sizing (and the refusal to give a universal formula), work stealing, saturation, and bounding concurrency as a first-class design decision.

Which parts of this computation are independent, and what limits the speedup?

Fork/join, parallel reduce, map/reduce as a computational pattern, the overhead that makes parallelising small work slower, Amdahl and Gustafson as complementary intuitions, and work versus span as the real ceiling on a dependency graph.

Is the same operation applied to many items, or different operations at once?

SIMD and data parallelism against task parallelism, pipeline stages that let items occupy different stages simultaneously, fan-out/fan-in, scatter/gather and the tail-latency cost of waiting for the slowest branch.

How do independent tasks agree on when to proceed?

Barriers and latches, `Promise.all` and `gather` and what they do on failure, the sequential-await trap, and the counterweight: parallelising a call fan-out multiplies load on whatever is downstream. Thundering herds and single-flight coalescing.

Who owns this task, and what happens when nobody wants the answer?

Child tasks with a clear lifetime, cancellation as a first-class concern rather than an afterthought, propagation to children, timeouts against deadlines, and the orphaned background task nobody is waiting for and nobody stops.

Can we make coordination unnecessary instead of correct?

The strategies that reduce synchronization rather than perfecting it: immutability, copying versus sharing, copy-on-write snapshots, and optimistic against pessimistic concurrency control with the contention threshold that decides between them.

What shape does this problem already have a known answer for?

The pattern catalogue with problem, structure, trade-offs and failure modes for each — and the anti-patterns that show up in real code review: one global lock, unbounded spawning, locks held across I/O, swallowed task exceptions, and lock-free code written without a reason.

Why is eight cores not eight times faster?

Where the speedup goes: serial fractions, synchronization, memory bandwidth, cache locality destroyed by tasks bouncing between cores, NUMA, affinity, and the numerical fact that parallel reduction can change floating-point results.

The bug disappears when I add a log line. Now what?

Why concurrency bugs resist ordinary debugging, and what works anyway: lock wait metrics, thread and async task dumps, contention profiling, race detectors, deterministic replay, and stress testing designed to shake out schedules that normal runs never produce.

Which concurrency model should this server use?

Thread-per-request against event-driven against hybrid runtimes, UI thread constraints, how databases solve concurrency for data but not for your application memory, and the boundary where a local mutex stops meaning anything at all.

Can these tool calls run at the same time?

Parallel tool execution and what it costs in load, money and determinism; agents racing on the same document; and cancelling a long-running agent run without leaving tool calls, queue entries and side effects behind.