What Is the GIL in Python?

The Global Interpreter Lock is a mutex inside the CPython interpreter. Only one thread can be executing Python bytecode at any moment, so two threads in one process cannot run Python code in parallel.

What it does not stop is the concurrency that actually matters for most applications. A thread that is blocked on I/O — reading a socket, waiting on a database, sleeping — releases the GIL, so other threads keep running while it waits. That is why threads are the right tool for I/O-bound work: a thousand threads waiting on network responses can all be in flight in one process, and the GIL only matters while one of them is actually computing.

What it does stop is parallel execution of CPU-bound Python code. Two threads each running a tight numerical loop will not finish in half the time, because they take turns holding the lock rather than running at the same time. The same work in two processes does run in parallel, because each process has its own interpreter and its own GIL.

Two clarifications to have ready. The GIL is an implementation detail of CPython, not a language guarantee, and CPython 3.13 and later have work in progress to make it optional so that free-threaded builds can run Python code truly in parallel. And the GIL is per-interpreter, not global across the machine — several processes can run Python code simultaneously on different cores. That is why multiprocessing, rather than threading, is the answer for CPU-bound work in Python.

Timing the same CPU-bound work sequentially and across two threads shows the GIL's effect directly.

import threading
import time


def burn(n):
    total = 0
    for i in range(n):
        total += i * i
    return total


def timed(label, work):
    start = time.perf_counter()
    work()
    print(f"{label}: {time.perf_counter() - start:.3f}s")


def sequential():
    burn(1_500_000)
    burn(1_500_000)


def threaded():
    threads = [threading.Thread(target=burn, args=(1_500_000,)) for _ in range(2)]
    for thread in threads:
        thread.start()
    for thread in threads:
        thread.join()


timed("sequential", sequential)
timed("threaded  ", threaded)

The two timings come out roughly the same. If the threads were genuinely running in parallel on two cores, the threaded version would take about half as long. It does not, because only one thread can hold the GIL at a time, so the second thread waits while the first one computes.

Two details about the measurement. The join calls matter — without them the main thread would race ahead and print before the workers had finished. And the absolute numbers depend on the machine, so the useful comparison is the ratio between the two lines rather than the values themselves.

The fix for CPU-bound work is multiprocessing rather than threading. Each process gets its own interpreter and its own GIL, so the two halves really do run at the same time on different cores. The cost is that processes have separate memory, so they cannot share ordinary Python objects — state has to be passed through a queue or a pipe, and the data has to be picklable.

A counter shared between threads without a lock loses updates, because the read-modify-write is not atomic.

import threading

counter = 0
lock = threading.Lock()


def increment():
    global counter
    for _ in range(100_000):
        with lock:
            counter += 1


threads = [threading.Thread(target=increment) for _ in range(2)]
for thread in threads:
    thread.start()
for thread in threads:
    thread.join()

print(counter)      # 200000

The final count is 200000, which is exactly what two threads each adding 100000 should produce. The with lock block makes the read and the write a single indivisible step, so no increment can be lost.

Without the lock the result would usually be less than 200000, and the exact number varies between runs. The reason is that counter += 1 is three bytecodes — load the value, add one, store it back — and the GIL can be released between them. Two threads can both read the same value and both store the incremented result, so one increment disappears.

This is the classic demonstration that the GIL does not make shared mutable state safe. It stops two threads from executing bytecode at the same instant, but it does not make a multi-step operation atomic, and it can switch threads between bytecodes.

Two things to add for an interview. The lock is required here because the state is shared, and in general the rule is to avoid shared mutable state between threads rather than to lock everything. And note that the lock is held only for the increment, not for the whole loop — a coarse lock would serialise the threads entirely.