Concurrency Execution Models¶

They're not different severities of the same bug — they're opposite failure shapes. A race condition is a correctness bug: the program keeps running, but the outcome depends on timing/interleaving that shouldn't matter, and it silently produces a wrong result (the lost-increment example in Concurrency Basics). A deadlock is a liveness bug: the program stops making progress entirely — threads are still "running" in the sense of existing, but every one of them is permanently blocked waiting on something another blocked thread holds. The practical distinction that matters in production: a race condition can run for months producing subtly wrong data before anyone notices, while a deadlock is usually loud and immediate — the request just never comes back. You debug them differently too: a race needs a way to reproduce a specific interleaving (often the hard part); a deadlock needs a thread dump showing the cycle, which most runtimes can produce directly.

A mutex isn't free even when there's no contention — acquiring and releasing it typically requires a memory barrier (see question 6) and, in the contended case, a trip through the OS scheduler to park and wake threads, which costs far more than the few nanoseconds of work the lock might be protecting. If the critical section is tiny (incrementing a counter) and contention is high (many threads hitting it constantly), the overhead of lock acquisition/release and the resulting context switches can dwarf the actual work being protected — you can end up with threads spending more time fighting over the lock than doing useful work, a pattern sometimes called "lock convoy." This is exactly why atomic primitives (compare-and-swap-based counters) exist: they get the same correctness guarantee for simple operations without the scheduler-level cost of a full mutex, because they resolve contention with a hardware-level retry loop instead of blocking and waking threads.

A lock-free structure guarantees system-wide progress: while operations continue taking steps, some operation completes even if another thread is delayed or suspended. It does not guarantee that every individual operation finishes within a bounded number of its own steps; an unlucky operation may repeatedly lose a race and starve. That stronger per-operation guarantee is called wait-free. Lock-free structures are typically built with atomic compare-and-swap operations in a retry loop instead of a mutex: read the current state, compute the new state, atomically swap only if nothing else changed it in between, and retry if it did. Avoid one when: the update logic is complex enough that expressing it atomically is awkward or requires copying large amounts of state per attempt; when you need composability across multiple operations; or, most practically, when a much simpler mutex-based version isn't actually your bottleneck yet. Lock-free code is meaningfully harder to implement and reason about, so profiling should justify that complexity.

Concurrency is about structure — a program is designed to handle multiple tasks that can be in progress at the same time, making independent forward progress, without implying they execute at the literal same instant. Parallelism is about execution — multiple tasks actually running at the same physical instant, which requires multiple cores. A single-core machine running an event loop (Node.js-style) is concurrent but never parallel — it interleaves tasks, never truly overlapping their execution. A multi-core machine running a work-stealing pool over a CPU-bound recursive algorithm is both. The distinction matters practically because they solve different problems: concurrency is the right tool for waiting well (handling thousands of slow, mostly-idle connections without one blocking the rest); parallelism is the right tool for going faster on CPU-bound work by literally using more cores at once. Reaching for more threads to solve a problem that's actually I/O-wait-bound (concurrency) rather than compute-bound (parallelism) is a common and costly category error.

A "fair" lock guarantees threads acquire it in the order they requested it (typically FIFO), which prevents one specific starvation mode — a thread being perpetually skipped by an unlucky-timing unfair lock. But fairness only governs that one lock. A thread can still starve if: it's waiting on a fair lock that's simply held for a long time by whoever's ahead in the (fair) queue, so "fair" doesn't mean "fast"; it's competing for CPU scheduling time separately from the lock itself, and the OS scheduler (which fairness doesn't control) deprioritizes it; or it depends on a chain of resources where each individual lock is fair but the combined wait compounds. Fairness also has a real cost — a fair lock is typically slower under low contention than an unfair one, because it enforces strict ordering instead of letting whichever thread happens to be running grab the lock immediately, so "just make every lock fair" isn't a free fix and is itself a trade-off, not a default.

Modern CPUs and compilers reorder instructions and cache memory operations aggressively for performance, as long as the reordering is invisible to a single thread's own view of its own execution. That guarantee says nothing about what other threads observe — without a memory barrier (a.k.a. fence), a write your thread makes might sit in a CPU's local cache or store buffer and simply not be visible to another core for an unbounded time, or become visible out of the order your code actually wrote it in. A memory barrier is an instruction that forces ordering and visibility guarantees at that point — "everything written before this barrier is visible to other cores that see this barrier." You rarely think about it directly because every standard synchronization primitive (a mutex, an atomic operation, a channel send in Go) has the necessary barriers built into its implementation — acquiring a lock implies an acquire barrier, releasing one implies a release barrier. You only need to reason about barriers explicitly when you're writing lock-free code yourself or using low-level atomic operations with relaxed memory ordering, which is precisely why that code is so much harder to get right than code built on standard locks.

Because "reading" a shared variable without synchronization gives no guarantee about when a write from another thread becomes visible to the reader — this is the visibility half of the memory-barrier problem in question 6, distinct from the atomicity problem race conditions are usually explained with. A classic case: thread A sets a done flag to true after finishing setup; thread B spins reading done waiting for it to flip. Without a memory barrier tying the flag to the setup work, the compiler or CPU is free to reorder A's writes so the flag becomes visible to B before the setup work it was supposed to signal is actually visible — B sees done = true and reads uninitialized or partially-initialized state. This is also the mechanism behind "torn reads": on some platforms, a multi-word value (a 64-bit value on a 32-bit system, or certain object references) can be read as an inconsistent mix of an old and new write if the write itself wasn't atomic. The fix, as with question 6, is using a properly synchronized primitive (an atomic type, a lock, a language-level "volatile"/happens-before construct) rather than a plain shared variable, even when it looks like "just reading" should be safe.

Pessimistic locking assumes conflict is likely and prevents it up front — acquire the lock before touching the shared resource, and every other thread blocks until you release it (a database SELECT ... FOR UPDATE, or the mutex-based try_occupy() in Concurrency Basics). Optimistic locking assumes conflict is rare and checks for it after the fact instead — read the current state and a version marker, do your work without holding any lock, then attempt to commit only if the version marker hasn't changed since you read it (a WHERE version = ? update, or a compare-and-swap loop), retrying if it has. The trade-off is about contention level: pessimistic locking wastes time making threads wait even when they'd never have actually conflicted, but guarantees no wasted work; optimistic locking lets everyone proceed without blocking, but wastes real work (and needs a retry) whenever a conflict actually does happen. Under low contention, optimistic wins easily — most attempts succeed on the first try with zero blocking. Under high contention, pessimistic can win, because optimistic's retry storm (many threads repeatedly recomputing and re-attempting) can cost more than blocking would have.

Past a certain point, more threads means more contention for the same finite resources — cores, memory bandwidth, cache lines, locks — and the coordination cost of managing that contention grows faster than the useful work being added. Concretely: more threads than CPU cores means the OS scheduler is now context-switching between them, and each context switch has real overhead (saving/restoring registers, flushing pipeline state, often invalidating cache locality) that produces zero useful work. If those threads are also contending for a shared lock, more threads past the point of saturation just means a longer queue waiting on the same serialized critical section — the lock, not the thread count, was the actual ceiling, and adding threads beyond it only adds scheduling overhead on top of an already-saturated bottleneck. This is a direct instance of Amdahl's Law: the speedup from parallelism is capped by the fraction of work that's inherently serial, and once you're past that ceiling, additional parallelism buys nothing and starts actively costing more in coordination than it returns.

It depends on the lock and runtime; there is no safe general rule that a mutex is automatically released. A normal POSIX mutex, for example, may remain locked indefinitely if its owner terminates. A mutex explicitly configured as robust can instead report owner death to the next acquirer, which must repair the protected state before marking the mutex consistent. Runtime-managed monitors and language-level locks have their own termination semantics, so code must consult that primitive's contract. Even when ownership is released or recoverable, the protected data may be half-updated and must not simply be trusted. A distributed lock or lease has the same problem at another scale: TTLs and heartbeat renewal eventually remove a crashed holder, but fencing tokens or equivalent validation are needed to stop a delayed former holder from writing after its lease expires (see distributed locks and leases). A lock-free structure avoids abandoned lock ownership: one thread stopping mid-operation does not permanently prevent system-wide progress, although memory reclamation and multi-step invariants still require careful design.