The GIL, threads and processes

CPython has a global interpreter lock (GIL): within one process, only one thread executes Python bytecode at any moment. Threads take turns; the interpreter asks the running thread to hand over every few milliseconds (the switch interval), and a thread also releases the GIL whenever it blocks — sleeping, waiting on a socket, reading a file — and inside C code written to release it.

Two consequences carry most interview answers:

• I/O-bound work (HTTP calls, database queries, disk) speeds up with threads, because a waiting thread does not hold the GIL.
• CPU-bound pure-Python work (parsing, number crunching in loops) does not: the threads only take turns on one core. Use processes.

Python 3.13 added an optional, experimental free-threaded build (PEP 703) that runs without the GIL, and 3.14 made that build officially supported. It is still a separate build you choose to install: the default CPython, and the Python 3.12 these examples run on, has the GIL.

The GIL is not a lock for your data

The GIL keeps the interpreter's own structures consistent; it promises nothing about yours. n += 1 is several bytecodes — load n, add, store n — and the language does not guarantee they run as one step. If a thread is paused after its load and another thread updates n meanwhile, the first thread's store writes back a stale value and that update is lost. Any read-modify-write on shared state needs a threading.Lock, used with with lock:.

The bug is easy to miss. Current CPython only switches threads at certain points in the bytecode, so an unlocked += 1 loop often loses nothing in a quick test (it lost nothing in the run below), and on the free-threaded build nothing serialises the threads at all. The example forces the bad interleaving with a barrier, so the lost update shows every time, and then puts the same steps under a lock.

1import contextlib2import dis3import sys4import threading5 6count = 07 8 9def increment():10    global count11    count += 112 13 14def two_deposits(use_lock):15    account = {"balance": 100}16    lock = threading.Lock()17    both_read = threading.Barrier(2, timeout=1)18 19    def deposit():20        with lock if use_lock else contextlib.nullcontext():21            seen = account["balance"]  # read22            try:23                both_read.wait()  # until the other thread has read too24            except threading.BrokenBarrierError:25                pass  # it never could: the lock kept it out26            account["balance"] = seen + 10  # write back27 28    threads = [threading.Thread(target=deposit) for _ in range(2)]29    for t in threads:30        t.start()31    for t in threads:32        t.join()33    return account["balance"]34 35 36def run():37    box = [0]38 39    def unlocked():40        for _ in range(100_000):41            box[0] += 142 43    threads = [threading.Thread(target=unlocked) for _ in range(4)]44    for t in threads:45        t.start()46    for t in threads:47        t.join()48    return {49        "switch_interval_seconds": sys.getswitchinterval(),50        "bytecode_for_increment": [i.opname for i in dis.get_instructions(increment)],51        "unlocked_quick_test": box[0],52        "two_deposits_without_lock": two_deposits(False),53        "two_deposits_with_lock": two_deposits(True),54    }

Executors

concurrent.futures gives threads and processes the same interface. ThreadPoolExecutor(max_workers=n) runs submitted callables on at most n threads. executor.map(fn, items) returns results in input order, whichever finishes first; submit() plus as_completed() yields futures in completion order (futures that had already finished when you call it come first, in no particular order). A task's exception is re-raised when you ask for its result — and with map that ends the iteration, so the results after the failed one are never handed to you. To keep every result, submit each task and handle each future's exception on its own.

1import threading2import time3from concurrent.futures import ThreadPoolExecutor, as_completed4 5 6def fetch(name, seconds):7    time.sleep(seconds)  # stands in for a network call8    return name9 10 11def fetch_after(name, earlier):12    earlier.result()  # finish only once `earlier` has finished13    return name14 15 16def run():17    jobs = [("slow", 0.3), ("fast", 0.1), ("medium", 0.2)]18    with ThreadPoolExecutor(max_workers=3) as pool:19        in_order = list(pool.map(lambda job: fetch(*job), jobs))20 21        # completion order fixed by construction: fast, then medium, then slow22        fast = pool.submit(fetch, "fast", 0.3)23        medium = pool.submit(fetch_after, "medium", fast)24        slow = pool.submit(fetch_after, "slow", medium)25        by_completion = [f.result() for f in as_completed([slow, fast, medium])]26 27        met = threading.Barrier(3, timeout=5)28 29        def meet(name):30            met.wait()  # returns only once three threads are waiting at once31            return name32 33        together = list(pool.map(meet, ["a", "b", "c"]))34 35        got = []36        try:37            for value in pool.map(int, ["1", "x", "3"]):38                got.append(value)39        except ValueError as e:40            got.append(f"ValueError: {e}")41    return {42        "map": in_order,43        "as_completed": by_completion,44        "three_threads_at_once": together,45        "map_with_a_failure": got,46    }

Processes

multiprocessing and ProcessPoolExecutor run work in separate processes, each with its own interpreter, its own GIL and its own memory, so CPU-bound work really runs in parallel. The price: starting processes costs time, and a process pool pickles every task (the function and its arguments) and every result to move them between processes. A function is pickled by its importable name, so it must be defined at module level — not a lambda, not a nested function — and the arguments must be picklable. A global changed in a child process is invisible to the parent; results come back through return values, queues or pipes.

1import multiprocessing as mp2from concurrent.futures import ProcessPoolExecutor3 4counter = 05 6 7def bump(queue):8    global counter9    counter += 100       # changes the child's copy only10    queue.put(counter)   # the way back to the parent11 12 13def run():14    ctx = mp.get_context("fork")15    queue = ctx.Queue()16    child = ctx.Process(target=bump, args=(queue,))17    child.start()18    from_child = queue.get(timeout=5)19    child.join()20 21    def in_pool(fn, arg):22        with ProcessPoolExecutor(max_workers=1, mp_context=ctx) as pool:23            try:24                return pool.submit(fn, arg).result(timeout=10)25            except AttributeError as e:  # how 3.12 reports a local function26                return f"AttributeError: {e}"27 28    return {29        "child_reported": from_child,30        "parent_counter": counter,31        "child_exit_code": child.exitcode,32        "pool_with_builtin_abs": in_pool(abs, -7),33        "pool_with_lambda": in_pool(lambda x: x * 2, 7),34    }

For thousands of concurrent network waits, asyncio (next lesson) usually beats threads: one thread, no locks around every shared value, and very cheap tasks.

Common mistakes

• Adding threads to speed up a CPU-bound loop. With the GIL, the total time stays about the same, or gets worse.
• Assuming the GIL makes counter += 1 or check-then-set on a dict safe. Nothing promises the read and the write happen together; use a lock, and do not take a passing test as proof.
• Collecting results with as_completed and then treating them as being in input order.
• Passing a lambda to a process pool, or expecting a child process to update the parent's globals.

What interviewers ask

• What is the GIL, and why does Python still have threads? One thread runs bytecode at a time per process; threads still overlap waiting, so they suit I/O-bound work.
• Threads, processes or asyncio for this job? CPU-bound: processes. Blocking I/O with a moderate number of tasks: threads. Many concurrent network waits with async libraries: asyncio.
• Is x += 1 atomic in Python? Not guaranteed: it is a load, an add and a store, and another thread's update can land in between; CPython rarely splits them in practice, which is why the bug hides in tests.