CSC352 Notes on the Python GIL

Threads

From http://docs.python.org/library/multiprocessing.html

The Python interpreter is not fully thread safe. In order to support multi-threaded Python programs, there’s a global lock, called the global interpreter lock or GIL, that must be held by the current thread before it can safely access Python objects. Without the lock, even the simplest operations could cause problems in a multi-threaded program: for example, when two threads simultaneously increment the reference count of the same object, the reference count could end up being incremented only once instead of twice.

Therefore, the rule exists that only the thread that has acquired the global interpreter lock may operate on Python objects or call Python/C API functions. In order to support multi-threaded Python programs, the interpreter regularly releases and reacquires the lock — by default, every 100 bytecode instructions (this can be changed with sys.setcheckinterval()). The lock is also released and reacquired around potentially blocking I/O operations like reading or writing a file, so that other threads can run while the thread that requests the I/O is waiting for the I/O operation to complete.

Moral of the story

Only one thread at a time with Python

Solutions around the GIL?

Jython: uses Java threads

IronPython: all threads run concurrently

Multiprocessing

• Good presentation at http://www.slideshare.net/pvergain/multiprocessing-with-python-presentation
• Official description of feature at http://www.python.org/dev/peps/pep-0371/ (cached copy)
• New in Python 2.6
• Will use multiple cores
• Allows access to shared variables in shared memory, through special mechanisms.
• API similar to threading API