The Python GIL

The Global Interpreter Lock is a mutex in CPython (label: CPython — PyPy has one too, Jython and IronPython do not) that a thread must hold to execute Python bytecode. It exists because CPython’s memory management uses non-atomic reference counts and a lot of interpreter state that would otherwise need fine-grained locking on every object touch. One lock is simple and fast for single-threaded code, which is most Python code (How C++, JavaScript and Python Map onto the OS).

What it does *not* do: it does not stop the OS from scheduling Python threads on different cores, and it is released whenever a thread enters a blocking system call or a C function that opts out — sockets, file reads, time.sleep, hashlib, zlib, most of NumPy’s heavy kernels, database drivers. So an I/O-bound program with 50 threads genuinely overlaps its waiting, and a NumPy matrix multiply on 8 threads can use 8 cores.

What it does do: two threads running pure-Python loops take turns, so the wall-clock time is the same as one thread — often worse, because they contend for the lock and pay context switches. For CPU-bound Python the options are multiple processes (multiprocessing, ProcessPoolExecutor — separate interpreters, separate GILs, data crossed by pickling), moving the hot loop into C/Cython/Rust and releasing the GIL, or rewriting in a way that lets a library do the work.

For I/O-bound work the choice between threads and asyncio is not about the GIL at all — both are concurrency without parallelism — but about blocking libraries, code style and scale (Threads versus Async versus Processes). The failure to recognise: an async service that calls a synchronous database driver blocks the whole loop, GIL or not.