Threads, locks, and the things that go wrong

Google and Meta loops often ask one OS/concurrency question. Don't go in blind.

First, the on-ramp: why any of this matters

A computer feels like it does many things at once — music plays while you type while a download finishes. Underneath, a single CPU core can only run one stream of instructions at a time. The operating system fakes the "at once" by slicing time into tiny intervals and switching the core between tasks dozens of times a second. That switch — saving everything the current task was doing (its registers, its place in the code) and loading the next task's saved state — is called a context switch. It is not free: it costs time, and on modern CPUs it also throws away cached data the old task had warmed up. This is the bedrock distinction the rest of the lesson builds on, so let us pin down the two words people constantly mix up.

Process vs thread, defined precisely

A process is an instance of a running program with its own private address space — its own slice of memory that no other process can read or write directly. Open your code editor and your browser: two processes, each fenced off from the other. Because the fence is enforced by hardware, a crash in one process cannot corrupt another's memory, which makes processes safe but heavy. Creating one means asking the OS for a fresh address space and copying setup over.

A thread is a line of execution inside a process. A process starts with one thread (the one running main) and can spawn more. All threads of a process share that one address space — the same heap, the same globals, the same open files. That shared memory is why threads are cheap (no new address space) and fast to communicate (just read a shared variable). It is also the entire source of danger: when two threads write the same variable with no coordination, you get the race condition above. A context switch between two threads of the same process is cheaper than between processes, because the address space does not change — only the small per-thread state (registers, stack pointer, program counter) is swapped.

A concrete race condition, and the lock that fixes it

The walkthrough above told the story; here is the actual code. Two threads each increment a shared counter 100,000 times. The correct answer is 200,000. Run the unsafe version and you will usually get less — some increments evaporated exactly as the four-step diagram showed.

import threading

counter = 0

def bump():
    global counter
    for _ in range(100_000):
        counter += 1          # NOT atomic: read counter, add 1, write back

t1 = threading.Thread(target=bump)
t2 = threading.Thread(target=bump)
t1.start(); t2.start()
t1.join(); t2.join()        # join() = wait here until that thread finishes
print(counter)               # EXPECTED 200000 — but often prints e.g. 137422

The reason the answer comes out low is that counter += 1 is not an atomic operation — "atomic" means indivisible, an action that completes in one step with no chance of another thread observing it half-done. The += is really three separate machine steps (load, add, store), and a context switch can land between any two of them, letting the other thread read a stale value. The cure is to wrap the three steps in a critical section — the stretch of code that touches shared state and must not be run by two threads at once — and protect that section with a mutex/lock, an object only one thread can "hold" at a time. A second thread that tries to acquire a held lock blocks (sleeps) until the holder releases it.

import threading

counter = 0
lock = threading.Lock()     # the mutex

def bump():
    global counter
    for _ in range(100_000):
        with lock:           # acquire on entry, release on exit (even if it raises)
            counter += 1      # critical section: now read-add-write can't be interrupted by the other thread

t1 = threading.Thread(target=bump)
t2 = threading.Thread(target=bump)
t1.start(); t2.start()
t1.join(); t2.join()
print(counter)               # ALWAYS 200000 — the lock serializes the dangerous part

The lock does not make the work parallel — it does the opposite, forcing the critical section to run one thread at a time. That is the trade you are always making with locks: correctness in exchange for some lost concurrency. Keep critical sections as small as possible (lock late, unlock early) so threads spend most of their time outside the lock.

Deadlock, and how to dodge it

A deadlock is the worst-case outcome of locks: a set of threads each holds a lock the others need, and every one of them is asleep waiting forever. Nothing crashes; the program simply freezes. The canonical illustration is the dining philosophers problem — philosophers around a table, one fork between each pair, and each needs two forks to eat. If every philosopher grabs the fork on their left at the same time, each holds one fork and waits forever for the right one. The two-lock version below is the same trap with two threads and two mutexes:

import threading

fork_a = threading.Lock()
fork_b = threading.Lock()

def thread_one():
    with fork_a:          # grabs A first
        with fork_b:      # then wants B
            ...

def thread_two():
    with fork_b:          # grabs B first  <-- OPPOSITE ORDER: this is the bug
        with fork_a:      # then wants A — but thread_one is holding A
            ...
# If both run at once: thread_one holds A waiting for B, thread_two holds B waiting for A. Frozen.

A deadlock can only happen when all four Coffman conditions hold simultaneously — so breaking any single one makes deadlock impossible. The cleanest fix here breaks circular wait with lock ordering: pick a single global order for the locks and make every thread acquire them in that order. If both threads grab fork_a before fork_b, no cycle can form — whoever gets A first will also get B, finish, and release.

# FIX: both threads acquire in the SAME order (A then B). No cycle possible.
def thread_two_fixed():
    with fork_a:          # same order as thread_one now
        with fork_b:
            ...

Producer-consumer: the pattern that uses everything

The producer-consumer problem is the classic coordination puzzle: one or more producer threads generate items, one or more consumer threads use them, and they hand off through a shared bounded buffer (a fixed-capacity queue). Two things must be coordinated — mutual exclusion on the queue itself, and waiting: producers must pause when the buffer is full, consumers must pause when it is empty. The condition variable handles the waiting. cv.wait() atomically releases the lock and sleeps; when another thread calls cv.notify_all(), the sleeper wakes, re-acquires the lock, and re-checks its condition.

from threading import Lock, Condition

class BoundedBuffer:
    def __init__(self, cap):
        self.q = []; self.cap = cap
        self.lock = Lock(); self.cv = Condition(self.lock)

    def put(self, item):
        with self.cv:
            while len(self.q) == self.cap:
                self.cv.wait()
            self.q.append(item)
            self.cv.notify_all()

    def get(self):
        with self.cv:
            while not self.q:
                self.cv.wait()
            v = self.q.pop(0)
            self.cv.notify_all()
            return v

Why while and not if: a thread can wake from wait() even though nothing useful changed (a spurious wake-up), and even when a real notify happened, another woken thread may have already grabbed the only free slot before this one re-acquires the lock. Re-checking the predicate in a loop is therefore mandatory for correctness — an if would proceed on a false assumption.

Threads vs async, and a word on Python's GIL

Async (coroutines) is a different model for concurrency. Instead of the OS preemptively switching threads at unpredictable points, a coroutine runs until it voluntarily awaits — yielding control at a marked spot — and an event loop on a single thread runs the next ready coroutine. Because switches happen only at explicit await points, you have far fewer surprise interleavings, and you can have tens of thousands of coroutines cheaply (no per-thread OS stack). The catch: a coroutine that does heavy CPU work without awaiting blocks the whole loop. So the rule of thumb is async for I/O-bound work (waiting on network, disk, databases — lots of idle waiting to overlap) and threads or processes for CPU-bound work (real computation to spread across cores).

Thread pools

Creating a thread per task does not scale — thread creation has overhead and thousands of threads thrash the scheduler with context switches. A thread pool fixes this: you create a fixed set of worker threads once, and feed tasks into a shared queue (a producer-consumer setup, in fact — the pool's internals are exactly the pattern above). Idle workers pull the next task, run it, and loop back for more. This caps concurrency at a known number, reuses threads instead of churning them, and naturally applies back-pressure when work arrives faster than it can be done. Most languages ship one (Python's concurrent.futures.ThreadPoolExecutor, Java's ExecutorService).

Pitfalls to avoid

• Forgetting to lock every access. A lock only protects shared state if all readers and writers use the same lock. One unlocked access reintroduces the race.
• Holding a lock too long. Doing I/O or slow work inside a critical section serializes everything and kills throughput. Lock just the shared-state touch, nothing more.
• Inconsistent lock order. The deadlock above. If your code takes two locks anywhere, document and enforce one global order.
• Using if instead of while around wait(). Spurious wake-ups and lost races make this subtly wrong.
• Assuming x += 1 (or any read-modify-write) is atomic. It is not. Use a lock or an atomic primitive.
• Confusing concurrency bugs for "flaky tests." An intermittent failure that depends on timing is usually a race, not bad luck — chase it down rather than retrying.