Global Interpreter Lock (GIL)

Motivation: Race Conditions

Python uses reference counting for memory management. It means that objects created in Python have a reference count variable that keeps track of the number of references that point to the object. When this count reaches zero, the memory occupied by the object is released. For example:

>>> import sys
>>> a = []
>>> b = a
>>> sys.getrefcount(a)
3

In the above example, the reference count for the empty list object [] was 3. The list object was referenced by a, b and the argument passed to sys.getrefcount().

The problem was that this reference count variable needed protection from race conditions where two threads increase or decrease its value simultaneously.

If this happens, it can cause either leaked memory that is never released or, even worse, incorrectly release the memory while a reference to that object still exists. This can cause crashes or other "weird" bugs in your Python programs.

This reference count variable can be kept safe by adding locks to all data structures that are shared across threads so that they are not modified inconsistently. But adding a lock to each object or groups of objects means multiple locks will exist which can cause another problem—Deadlocks (deadlocks can only happen if there is more than one lock). Another side effect would be decreased performance caused by the repeated acquisition and release of locks.

The GIL is a single lock on the interpreter itself which adds a rule that execution of any Python bytecode requires acquiring the interpreter lock. In other words, only one thread gets executed at a time.

This prevents deadlocks (as there is only one lock) and doesn't introduce much performance overhead. But it effectively makes any CPU-bound Python program single-threaded.

Impact of GIL on Multithreading

GIL is friendly to I/O-bound programs but unfriendly to CPU-bound programs.

CPU-bound programs are those that are pushing the CPU to its limit. This includes programs that do mathematical computations like matrix multiplications, searching, image processing, etc.

I/O-bound programs are the ones that spend time waiting for I/O which can come from a user, file, database, network, etc. I/O-bound programs sometimes have to wait for a significant amount of time till they get what they need from the source due to the fact that the source may need to do its own processing before the input/output is ready, for example, a user thinking about what to enter into an input prompt or a database query running in its own process.

The GIL does not have much impact on the performance of I/O-bound multi-threaded programs as the lock is shared between threads while they are waiting for I/O. But a program whose threads are entirely CPU-bound, e.g., a program that processes an image in parts using threads, would not only become single threaded due to the lock but will also see an increase in execution time in comparison to a scenario where it was written to be entirely single-threaded. This increase is the result of acquire and release overheads added by the lock.

Bypass GIL Restrictions

The most popular way to deal with GIL is to use a multiprocessing approach where you use multiple processes instead of threads.

Each Python process gets its own Python interpreter and memory space so the GIL won't be a problem. Python has a multiprocessing module which lets us create processes easily like this:

from multiprocessing import Pool
import time

COUNT = 50000000
def countdown(n):
    while n>0:
        n -= 1

if __name__ == '__main__':
    pool = Pool(processes=2)
    start = time.time()
    r1 = pool.apply_async(countdown, [COUNT//2])
    r2 = pool.apply_async(countdown, [COUNT//2])
    pool.close()
    pool.join()
    end = time.time()
    print('Time taken in seconds -', end - start)
    # Time taken in seconds - 4.060242414474487

Reference

What Is the Python Global Interpreter Lock (GIL)? – Real Pythonrealpython

What Is the Python Global Interpreter Lock (GIL)? - Real Python