Python Guru Series ??????- Part 3: Global Interpreter Lock (GIL)

Hello everyone, in the previous article we explored the common interpreters in Python. We also observed the impact of interpreters on the performance of Python programs in certain specific tasks.

CPython is the default interpreter of Python, supporting all Python distributions. CPython is well-known for implementing the Global Interpreter Lock (GIL), which makes Python a single-threaded language.

Today, we will learn about GIL. The role and the impact of GIL on the Python language.

What is the Global Interpreter Lock (GIL)

The Python Global Interpreter Lock or GIL, in simple words, is a mutex (or a lock) that protects access to Python objects and allows only one thread to hold the control of the Python interpreter. This means that only one thread can be in a state of execution at any point in time even if running on a multi-core processor.

The effect of GIL on Multi-threading programs

The impact of the GIL isn’t visible to developers who execute single-threaded programs. However, the biggest impact of the GIL is that it can create a significant bottleneck for programs executing CPU-bound tasks or tasks that leverage multi-threading capabilities. Let’s consider two examples below.

Code 1: The CPU-bound program that performs simple countdown

Output:

Completed in 3.0810108184814453        

Code 2: Two threads running parallel perform simple countdown

Output:

Completed in 3.1420132384019721        

The program was executed on a PC with an Intel Core i3-10100 processor, 4 cores and 8 threads, and 32GB RAM.

As you can see from the two examples above, the single-threaded program executed faster than the multi-threaded program. This means that applying multi-threading did not improve the execution time of the program. On the contrary, it increased the execution time due to the overhead of forking threads at the start and joining threads at the end of the program.

Why does the GIL still exist?

From the very beginning, along with the development of CPython, the GIL was designed to ensure thread safety in Python. It also set the foundation for Guido van Rossum to provide flexibility in application development for the language.

1.Compatibility

Many Python packages (and the main Python interpreter, CPython) heavily use C extensions, which aren’t inherently thread-safe. It’s possible to get multiple threads to try and access the same resources, which can lead to extremely negative effects. The GIL made it safer to create and use C extensions, which in turn made it easier for developers in the 90s to start using Python to create software, driving adoption.

2.Garbage Collection and Reference Counting

Another important reason has to do with how Python handles garbage collection. Garbage collection is an automatic memory management process where the interpreter tracks and reclaims memory occupied by objects that are no longer referenced or reachable in the program. In Python, there are two main methods of garbage collection, but the most prominent is a process called reference counting.

Reference counting in Python is an efficient way to manage memory and ensure that resources are released when they are no longer in use, helping to prevent memory leaks in Python programs. Reference counting works like this:

• Each object keeps track of the number of references pointing to it.
• When an object's reference count drops to zero, it means there are no more references to that object in the program.
• This indicates that the object is no longer needed.
• Python's memory management system automatically reclaims the memory occupied by the object, effectively deleting it.

Without the GIL, multiple threads running concurrently could manipulate reference counts of objects simultaneously, leading to race conditions and memory corruption. The GIL acts as a safeguard, allowing only one thread to execute Python bytecode at a time, preventing these potential issues.

You may wonder why the GIL still exists despite its limitations.

The truth is, there have been many efforts in the past to remove the GIL from CPython. However, this task is considered highly challenging and demanding, potentially leading to a complete restructuring of Python's ecosystem.

Some interpreters like PyPy, developed from a restricted subset of Python, still have the GIL but focus on improving the execution speed of Python code through Just-In-Time (JIT) compilation at runtime. Other interpreters like Jython and IronPython do not have the GIL in their design because they take advantage of the runtime capabilities of the respective Java and .NET environments. However, the limitation of using these interpreters is that many libraries in Python, written in C, are not supported as they are in CPython. These interpreters only support specific Python distributions to solve certain narrow problems.

Efforts to improve Python's performance are ongoing. Since Python 3.4, with the introduction of Asyncio, performance has improved significantly by allowing concurrent execution without multiple threads. Additionally, numerous efforts have been made to continuously enhance the capabilities of the language.

Summary

Everything has two sides, and the GIL is no exception. On one hand, it helps manage memory and makes it easier for developers to write code. On the other hand, it presents performance issues with multi-threading in the context of modern multi-core, multi-threaded machines.

The existence of the GIL will always be a hot topic when discussing Python.

However, despite its inherent issues, Python continues to shine in fields like Big Data, AI, and Web Development, with many successful applications. Recent signals from Python updates indicate that the future of Python holds promising developments.

In the next article, we will discuss ways to overcome the limitations of the GIL to speed up your Python programs.

Again, I am Phan. A curious and dedicated developer.

Reference:

Python GIL - The RealPython

Python Guru Series

Python Guru Series - Part 1: The Python Overview

Python Guru Series - Part 2: The Python's Interpreters