In CPython, the global interpreter lock, or GIL, is a mutex that prevents multiple native threads from executing Python bytecodes at once. This lock is necessary mainly because CPython's memory management is not thread-safe. (However, since the GIL exists, other features have grown to depend on the guarantees that it enforces.)

CPython extensions must be GIL-aware in order to avoid defeating threads. For an explanation, see [http://docs.python.org/api/threads.html Global interpreter lock].

The GIL is controversial because it prevents multithreaded CPython programs from taking full advantage of multiprocessor systems in certain situations. Note that potentially blocking or long-running operations, such as I/O, image processing, and NumPy number crunching, happen outside the GIL. Therefore it is only in multithreaded programs that spend a lot of time inside the GIL, interpreting CPython bytecode, that the GIL becomes a bottleneck.

Another issue with removing the GIL is the current ease of incorporating external libraries without having to worry about threading; libraries that wish to deal with a threaded environment must explicitly choose to do so.

Non-CPython implementations

Jython and IronPython have no GIL and can fully exploit multiprocessor systems.

[Mention place of GIL in StacklessPython.]

Eliminating the GIL

Getting rid of the GIL is an occasional topic on the python-dev mailing list. No one has managed it yet. The following properties are all highly desirable for any potential GIL replacement; some are hard requirements.

• Simplicity. The proposal must be implementable and maintainable in the long run.

• Concurrency. The point of eliminating the GIL would be to improve the performance of multithreaded programs. So any proposal must show that it actually does so in practice.

• Speed. The ["BDFL"] has said he will reject any proposal in this direction that slows down single-threaded programs. (citation needed) Note that this is harder than it looks. The existing reference count mechanism is very fast in the non-concurrent case, but means that almost any reference to an object is a modification (at least to the refcount); many concurrent GC algorithms assume that modifications are rare.

• Features. The proposal must support existing CPython features including __del__ and weak references.

• Source compatibility. The proposal should be source-compatible with the macros used by all existing CPython extensions (Py_INCREF and friends). See [http://docs.python.org/api/countingRefs.html Python/C API Reference Manual: Reference Counting].

• Prompt destruction (nice to have?). The existing reference-counting scheme destroys objects as soon as they become unreachable, except for objects in reference cycles. Those are collected later by Python's cycle collector. Some CPython programs depend on this, e.g. to close files promptly, so it would be nice to keep this feature.

• Ordered destruction (nice to have?). Barring cycles, Python currently always destroys an unreachable object X before destroying any other objects referenced by X. This means all the object's attributes are still there when __del__ runs. (Many garbage collection schemes don't guarantee this.)

Source compatibility is an especially difficult problem. All concurrent memory management schemes we've found rely on one or more of the following techniques, all of which are non-source-compatible with existing CPython extensions.

• Tracing. Most garbage collectors need to be able to start with an object and enumerate all the objects that it points to. The builtin CPython pointer-containing types, like PyList and PyDict, all have a tp_traverse method that can do this, but not all extension types have that method.

• Write barriers. A write barrier is a small piece of code that executes whenever a pointer variable is modified. Alas, no matter how you hack the Py_INCREF etc. macros, you can't make a write barrier hook out of them. Even if you could, many schemes require a different write barrier for stack variables vs. global variables vs. object fields that point to other objects; nothing in the Python/C API makes that distinction.

• Exact stack information. Exact garbage collection schemes need to be able to mark all objects reachable from local C variables. To do this, some schemes need to know where such variables are located on the C stack (and/or registers)--something CPython does not currently track.

It is barely credible that CPython might someday make tp_traverse mandatory for pointer-carrying types; adding support for write barriers or stack bookkeeping to the Python/C API seems extremely unlikely.