What does CPython's GIL actually protect inside the interpreter?

## The invariant that needs protecting Ask why the GIL exists and the answer is not "because threading is hard" but something much more specific: **CPython mutates shared interpreter state on almost every bytecode instruction, and the most frequently mutated piece of that state is the per-object reference count.** Every object CPython allocates carries a counter of how many references currently point at it. Binding a name, pushing a value on the evaluation stack, passing an argument, returning a result, storing into a list — each of these adjusts counters, and so does simply reading a value, because the reader takes a reference while it works. A trivial loop performs millions of these updates a second. A counter update is read-modify-write. Two threads doing it on the same object with no synchronisation can interleave so that one update is lost. Lose an increment and the count reaches zero while a live reference still exists, so the object is freed underneath a thread that is using it, which is a use-after-free crash or silent corruption. Lose a decrement and the object is never freed, which is a leak. Neither failure is reproducible, and both surface far from the code that caused them. ## Why one big lock rather than many small ones The obvious alternative is to make refcount updates atomic, or to lock each object. Both were tried, historically and recently, and both are expensive for the common case: * An atomic increment is far more costly than a plain one, and it forces cache-line ownership to bounce between cores whenever two threads touch the same hot object — and in Python the hottest objects are shared by construction: `None`, `True`, small integers, interned strings, every module and class object. * Fine-grained per-object locks multiply that cost and introduce lock ordering, which means deadlock risk in the interpreter itself. One coarse lock, held for the duration of bytecode execution, makes the whole question disappear. Inside the lock, a refcount update is an ordinary non-atomic integer operation on memory only one thread can be touching. Single-threaded programs — still the overwhelming majority — pay essentially nothing. ## What else it covers Reference counts are the headline, but the GIL is a blanket over CPython's shared mutable internals generally: the object allocator's freelists and arenas, various internal caches, and assorted interpreter bookkeeping. Because bytecode execution is serialised, none of these needed their own synchronisation, and decades of interpreter code was written on that assumption. That accumulated assumption, not the lock itself, is the reason removing the GIL has been such a long project. ## What it does not protect This is the part interviews probe, so be precise. The GIL guarantees that the interpreter's *own* structures stay consistent. It guarantees nothing about the consistency of *your* multi-step operations, because it is released and reacquired between bytecode instructions. An operation that reads a value, computes a new one and stores it back is several instructions, and a thread switch can land between any two of them. Application-level invariants still need application-level synchronisation. ## The naming subtlety "Global" is now slightly historical. Since 3.12 (PEP 684) each interpreter in a process can own its own GIL, so the lock is interpreter-wide rather than process-wide; 3.14 exposes multiple interpreters from the standard library as `concurrent.interpreters` and an interpreter-backed executor (PEP 734). Two interpreters in one process can therefore execute bytecode simultaneously — because they do not share the object state the lock protects. ## What changes when the lock goes away The free-threaded build, experimental in 3.13 and officially supported in 3.14 (PEP 779), does not simply delete the lock. It has to replace what the lock was doing: biased and deferred reference counting so that the hottest objects avoid contention, immortal objects whose counts are never touched, atomic operations where they are unavoidable, and per-object locking for containers. The measured price is a 5 to 10 percent single-threaded slowdown, which is exactly the cost the GIL was originally buying away. ## How to say it in an interview A strong answer is three beats. One: CPython refcounts every object, and refcount updates are read-modify-write on shared memory. Two: making each of those safe individually would tax the single-threaded case that dominates, so CPython serialises bytecode execution with a single lock instead. Three: the lock keeps the *interpreter* consistent, not your data structures. If you can add that removing it means replacing the mechanism rather than deleting it, you have said everything the question is looking for.