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). Good reading of how performance was measured.
- 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
