More on the Global Interpreter Lock
Although it’s a lower-level topic than you generally need to do useful thread work in
Python, the implementation of Python’s threads can have impacts on both performance
and coding. This section summarizes implementation details and some of their
ramifications.
Threads implementation in the upcoming Python 3.2: This section de-
scribes the current implementation of threads up to and including Py-
thon 3.1. At this writing, Python 3.2 is still in development, but one of
its likely enhancements is a new version of the GIL that provides better
performance, especially on some multicore CPUs. The new GIL imple-
mentation will still synchronize access to the PVM (Python language
code is still multiplexed as before), but it will use a context switching
scheme that is more efficient than the current N-bytecode-instruction
approach.
Among other things, the current sys.setcheckinterval call will likely
be replaced with a timer duration call in the new scheme. Specifically,
the concept of a check interval for thread switches will be abandoned
and replaced by an absolute time duration expressed in seconds. It’s
anticipated that this duration will default to 5 milliseconds, but it will
be tunable through sys.setswitchinterval.
Moreover, there have been a variety of plans made to remove the GIL
altogether (including goals of the Unladen Swallow project being con-
ducted by Google employees), though none have managed to produce
any fruit thus far. Since I cannot predict the future, please see Python
release documents to follow this (well...) thread.Strictly speaking, Python currently uses the global interpreter lock (GIL) mechanism
introduced at the start of this section, which guarantees that one thread, at most, is
running code within the Python interpreter at any given point in time. In addition, to
make sure that each thread gets a chance to run, the interpreter automatically switches
its attention between threads at regular intervals (in Python 3.1, by releasing and ac-
quiring the lock after a number of bytecode instructions) as well as at the start of long-
running operations (e.g., on some file input/output requests).
This scheme avoids problems that could arise if multiple threads were to update Python
system data at the same time. For instance, if two threads were allowed to simultane-
ously change an object’s reference count, the result might be unpredictable. This
scheme can also have subtle consequences. In this chapter’s threading examples, for
instance, the stdout stream can be corrupted unless each thread’s call to write text is
synchronized with thread locks.
Moreover, even though the GIL prevents more than one Python thread from running
at the same time, it is not enough to ensure thread safety in general, and it does not
Threads | 211