Concurrency

/reɪs kənˈdɪʃən/

noun — "outcome depends on timing, not logic."

Race Condition is a concurrency error that occurs when the behavior or final state of a system depends on the relative timing or interleaving of multiple executing threads or processes accessing shared resources. In a race condition, two or more execution paths “race” to read or modify shared data, and the result varies depending on which one happens to run first. This makes the system nondeterministic: the same code, given the same inputs, may produce different results across executions.

Technically, a race condition arises when three conditions are present simultaneously. First, multiple execution units run concurrently. Second, they share mutable state, such as memory, files, or hardware registers. Third, access to that shared state is not properly coordinated using synchronization mechanisms. When these conditions align, operations that were assumed to be logically atomic are instead split into smaller steps that can interleave unpredictably.

A classic example is incrementing a shared counter. The operation “counter = counter + 1” is not a single indivisible action at the machine level. It involves reading the current value, adding 1, and writing the result back. If two threads perform this sequence concurrently without synchronization, both may read the same initial value and overwrite each other’s updates, resulting in a lost increment.

# conceptual sequence without synchronization
Thread A reads counter = 10
Thread B reads counter = 10
Thread A writes counter = 11
Thread B writes counter = 11   # one increment lost

From the system’s perspective, nothing illegal occurred. Each instruction executed correctly. The error emerges only at the semantic level, where the intended invariant “each increment increases the counter by 1” is violated. This is why race conditions are particularly dangerous: they often escape detection during testing and appear only under specific timing, load, or hardware conditions.

Race conditions are not limited to memory. They can occur with file systems, network sockets, hardware devices, or any shared external resource. For example, two processes checking whether a file exists before creating it may both observe that the file is absent and then both attempt to create it, leading to corruption or failure. This class of bug is sometimes called a time-of-check to time-of-use (TOCTOU) race.

Preventing a race condition requires enforcing ordering or exclusivity. This is typically achieved using synchronization primitives such as mutexes, semaphores, or atomic operations. These tools ensure that critical sections of code execute as if they were indivisible, even though they may involve multiple low-level instructions. In well-designed systems, synchronization also establishes memory visibility guarantees, ensuring that updates made by one execution context are observed consistently by others.

However, eliminating race conditions is not just about adding locks everywhere. Over-synchronization can reduce concurrency and harm performance, while incorrect lock ordering can introduce deadlocks. Effective design minimizes shared mutable state, favors immutability where possible, and clearly defines ownership of resources. Many modern programming models encourage message passing or functional paradigms precisely because they reduce the surface area for race conditions.

Conceptually, a race condition is like two people editing the same document at the same time without coordination. Each person acts rationally, but the final document depends on whose changes happen to be saved last. The problem is not intent or correctness of individual actions, but the absence of rules governing their interaction.

See Synchronization, Mutex, Thread, Deadlock.

/ˌmʌltiˈprəʊsɛsɪŋ/

noun … “Multiple processes running in parallel.”

Multiprocessing is a computing technique in which multiple independent processes execute concurrently on one or more CPUs or cores. Each process has its own memory space, file descriptors, and system resources, unlike Threading where threads share the same memory. This isolation allows true parallel execution, enabling CPU-bound workloads to utilize multi-core systems efficiently and avoid limitations imposed by mechanisms like the GIL in Python.

Key characteristics of Multiprocessing include:

• Process isolation: memory and resources are separate, reducing risks of data corruption from concurrent access.
• True parallelism: multiple processes can run simultaneously on separate cores.
• Inter-process communication (IPC): data can be exchanged using pipes, queues, shared memory, or sockets.
• Overhead: processes are heavier than threads, requiring more memory and context-switching time.

In a typical workflow, a Python developer performing CPU-intensive image processing might create a pool of worker processes using the multiprocessing module. Each process operates on a subset of the dataset independently. Once all processes finish, results are collected and combined. Unlike Threading, this approach achieves near-linear speedup proportional to the number of cores, because each process executes bytecode independently of the GIL.

Example usage in Python:

from multiprocessing import Pool

def square(x):
    return x * x

with Pool(4) as p:
    results = p.map(square, [1, 2, 3, 4])
print(results)

Here, four separate processes compute the squares in parallel, and the results are aggregated once all computations complete.

Conceptually, Multiprocessing is like having multiple independent kitchens preparing dishes simultaneously. Each kitchen has its own ingredients, utensils, and chef, so tasks proceed in parallel without interference, unlike multiple chefs sharing a single workspace (as in Threading).

See Threading, Global Interpreter Lock, Python, Concurrency.

/ˈθrɛdɪŋ/

noun … “Parallel paths of execution within a program.”

Threading is a programming technique that allows a single process to manage multiple independent sequences of execution, called threads, concurrently. Each thread represents a flow of control that shares the same memory space, file descriptors, and resources of the parent process while maintaining its own program counter, stack, and local variables. Threading enables programs to perform multiple operations simultaneously, improving responsiveness and throughput, particularly in I/O-bound applications.

Threads are often managed either by the operating system, in which case they are called kernel threads, or by a runtime library, known as user-level threads. In languages like Python, the Global Interpreter Lock (GIL) restricts execution of Python bytecode to one thread at a time within a single process, meaning CPU-bound tasks cannot achieve true parallelism using Threading. For I/O-bound tasks, such as network requests or file operations, Threading remains highly effective because the interpreter releases the GIL during blocking calls.

Key characteristics of Threading include:

• Shared memory: threads operate within the same address space of the process, enabling fast communication but requiring synchronization mechanisms.
• Concurrency: multiple threads can appear to run simultaneously, especially on multi-core systems.
• Lightweight execution units: threads are less resource-intensive than separate processes.
• Synchronization challenges: race conditions, deadlocks, and data corruption can occur if shared resources are not properly managed.

Workflow example: A Python web server can spawn a thread for each incoming client connection. While one thread waits for network I/O, other threads handle additional requests, maximizing resource utilization and responsiveness. If a CPU-intensive task is needed, the server may offload the computation to separate processes to bypass the GIL and achieve parallel execution.

Conceptually, Threading is like having multiple couriers delivering packages from the same warehouse. They share the same stock (memory) and infrastructure but each follows its own route (execution path). Without proper coordination, couriers could interfere with each other, but with synchronization, deliveries proceed efficiently in parallel.

See Global Interpreter Lock, Multiprocessing, Python, Concurrency.

/ˌɛm viː siː ˈsiː/

n. — "Database sorcery keeping readers blissfully ignorant of writers' mayhem."

MVCC (Multi-Version Concurrency Control) stores multiple temporal versions of each database row, letting readers grab consistent snapshots without blocking writers—who append fresh versions instead of overwriting. Unlike 2PL locking wars, transactions see "their" reality via timestamps/transaction IDs, with garbage collection culling ancient corpses once safe.

Key characteristics and concepts include:

• Append-only updates birth new row versions; readers self-select via xmin/xmax or visibility maps.
• Snapshot isolation: each txn sees database as-of-its-start, dodging dirty/non-repeatable reads.
• Write skew possible (lost updates), vacuuming/autovacuum prunes dead tuples bloating tables.
• Zero reader-writer blocking, but storage bloat demands periodic cleanup unlike lock-free queues.

In PostgreSQL workflow, SELECT grabs xmin-snapshot → concurrent UPDATE creates xmax=new_version → SELECT still sees old → VACUUM reclaims post-txn.

Intuition anchor: picture MVCC as time-traveling databases where every query warps to txn-birth snapshot, writers scribble parallel timelines—CouchDB revision trees git-merge conflicts while PostgreSQL VACUUMs zombie rows.