concurrency

Slow software is slow for a short list of reasons, and each one has a signature you can recognise before you find the code. This lesson covers the six recurring bottleneck classes, waiting on I/O, chatty queries, allocation pressure, lock contention, memory access patterns and serialisation, with the symptom that identifies each and the fix that actually works.

Starting a goroutine is one keyword; stopping one is a design decision nothing forces you to make. A goroutine blocked forever is never collected and holds everything it references, which is the most common Go-specific bug. This lesson covers how leaks happen, the cancellation mechanism that prevents them, and how to detect the ones already there.

Cheap concurrency without a coordination primitive is a bug generator. Go's answer is a typed conduit that carries values between goroutines, from a 1978 idea: rather than protecting shared state with locks, pass ownership through a channel so there is no sharing to protect. This lesson builds channels, select, and where the model does not fit.

A thread costs enough that programs are architected around not having many. A goroutine costs little enough that the constraint disappears, which changes what designs are available. This lesson explains where the saving comes from, what the runtime scheduler does with them, and what the abundance does not fix.

Rust did not add a concurrency safety mechanism. A data race requires aliasing plus mutation, which the borrow checker already forbids, so data races became compile errors as a side effect. This lesson shows how two marker traits extend that guarantee across threads, and what it still does not prevent.

The third tradition supplies no invariants and writes no proofs. It builds the set of states a system can reach and checks the property against all of them, which is decidable when that set is finite. This lesson covers what it buys, the state explosion that limits it, and the techniques that made it usable anyway.

Why CPython has a Global Interpreter Lock, what it does and does not protect, and how the three concurrency models differ. Then how PEP 703 free-threading removes the GIL using per-object locks and biased, deferred, and immortal reference counting, plus the tradeoffs that keep it opt-in.

Async Python from the bytecode up. Coroutines vs return values, how the event loop schedules tasks, when async beats threading or multiprocessing, structured concurrency with TaskGroup, and the cancellation rules that production backends live or die by.

Transactions are a promise. Learn the ACID guarantees, the exact anomalies each SQL isolation level prevents or allows, why two-phase locking blocks and MVCC does not, and how Postgres uses row versions plus a transaction ID visibility check to give you snapshot isolation without holding a single read lock.

Threads look deceptively simple — create a few, share some memory, done. In practice, shared mutable state is a minefield: race conditions, non-deterministic output, and bugs that vanish under a debugger. This lesson dissects concurrency vs parallelism, why `count++` is three operations the CPU can interleave, Amdahl's law, and what a critical section actually means.

The CPU and compiler silently reorder your code. Cache coherence does not mean coherent behavior. This lesson explains the happens-before relation, memory fences, C++ and Java atomic operations, compare-and-swap, and why `volatile` is not a synchronization primitive.

Mutexes, condition variables, semaphores, and reader-writer locks — the primitives that make concurrent code correct. Understand the four Coffman deadlock conditions, how lock ordering prevents them, and why contention turns a performance win into a bottleneck.

Threads are not the only model for concurrency. Learn how blocking vs non-blocking I/O works, how the event loop and reactor pattern scale to millions of connections, and how callbacks evolved into futures, promises, and async/await — plus where coroutines fit and when async loses to threads.