The GIL: what it serialises and what it does not make safe

What it is

The glossary defines the global interpreter lock as the mechanism CPython uses to assure that only one thread executes Python bytecode at a time, which makes the object model, including built-in types such as dict, implicitly safe against concurrent access. The lock is released around blocking I/O and by extension code that opts in, which is why I/O-bound threads overlap and CPU-bound ones do not. A free-threaded build (--disable-gil) exists since 3.13; the free-threading guide states that on it, dict, list and set use internal locks to behave similarly to the GIL build, and that the GIL may be enabled automatically, with a printed warning, when a C extension module not marked as supporting free threading is imported.

Why it matters

"Python has a GIL, so my code is thread-safe" is a common misreading. The GIL guards the interpreter's data structures. It does not guard the program's invariants: a thread can be switched out between any two bytecodes, and most statements compile to several.

How to apply

• Treat every read-modify-write as unsafe: counter += 1, d[k] = d.get(k, 0) + 1, if key not in cache: cache[key] = compute(). Wrap them in with lock:; the documentation recommends the with statement over manual acquire()/release().
• Protect an invariant that spans several objects (two lists that must stay the same length) with one lock, not one lock per object.
• Use RLock when a locked method calls another locked method of the same object; a plain Lock is not reentrant and blocks its own thread.
• Hand work between threads through queue.Queue, which does its own locking.
• Do not design around the atomicity of single container operations; it holds only for specific C-implemented methods on the default build and is not a language guarantee.
• On a free-threaded build keep exactly the same locks; the guide states that sharing one iterator between threads may yield duplicate or missing elements.

Pitfalls

Code that works under the GIL because switches are rare fails under load or on another version. Holding a lock while calling unknown code (callbacks, logging handlers, __del__) invites deadlocks. A free-threaded interpreter does not prove the GIL is off: check sys._is_gil_enabled() at run time, since an unprepared extension may turn it back on.