One of the most controversial features in Python is the GIL or Global Interpreter Lock. It is essentially a big lock that allows only one thread to pass through the python interpreter at any given time. This prevents multi-threaded CPython programs from taking full advantage of the multiprocessor systems. Two days ago, the Python team officially accepted the proposal to remove this feature and also offered a short term and long term plan to do so. 

Understanding GIL

When Python was first publicly released in 1991, it didn’t support threads or have a global interpreter lock. Support for threads was added about a year later in 1992 together with the GIL. During that time, a number of operating systems added better support for threading and computers began coming with multiple processors.

Guido van Rossum, the creator of Python said in a recent interview, “We thought we had conquered the abstraction of threads pretty well because multi-core CPUs were not in most Python programmers’ hands anyway [in the ‘90s]. And then, chip designers put multiple CPUs on one chip, and suddenly there was all this pressure about doing things in parallel. And that’s the moment that GIL became infamous because it was the solution we used to take this single interpreter and share it between all the different operating system threads that you could create. And so as long as the hardware physically only had one CPU, that was all fine.”

Similar to Python, Linux and FreeBSD also had a system of global locks, the big kernel lock in linux and a lock called giant in FreeBSD. They also only allowed one thread to be processed at a time, by the interpreter. Over time, these locks were replaced by ‘fine-grained locking’ and other techniques to make things work faster and more efficiently. 

There were a few reasons why the GIL was retained in Python for so long. The lock was easy to implement and didn’t need complex coding. Not many programs required to run on multiple CPUs, and the single thread programs worked fast. The presence of the GIL avoided deadlocks, preventing certain types of bugs – ones that would crop up while using fine-grained locks. 

Why remove GIL now?

Developers are increasingly using Python to develop neural network-based AI models. These models can be made to work faster by exploiting multiple types of parallelism. GIL blocks this possibility, a drawback for Python whereas in other languages threads can be used to run different parts of an AI model in separate CPU cores. Similarly, when dealing with time-sensitive tasks, using threads to handle multiple requests at once also faces difficulties with Python’s GIL. There are other alternatives to GIL but this again is a tedious process which comes with significant limitations. 

Based on how users interact with Python, they are divided in whether GIL should be removed or not. The team at Python before making this announcement, conducted a poll last month saying, “We’re talking about long-term, invasive changes, and we want to know if there is general consensus on the idea of free-threading, and sufficient practical support for PEP 703.”

GIL Gone

The long and tedious process has begun. In the meanwhile, the Python Enhancement Proposal (PEP) allows a new build configuration flag that disables GIL in CPython, running without the lock. The team at Python are taking a cautious approach to making a change to avoid the fiasco of the Python transition from 2 to 3. 

The proposal is divided into a short-term experimental version where the GIL will be created for testing purposes. The mid-term stage begins after testing and community support where the free version is supported yet isn’t the default. In the long term the GIL free version will become the default Python interpreter while also ensuring backward compatibility. 

Led by Sam Gross, Meta has announced that they will dedicate a serious engineering team to this transformation. This is considered a win for the AI ecosystem. 

One of the interesting outcomes of this, is the redundancy of Rust while needing to compute multiple threads at the same time. Developers instead of turning to a different language, will now work with Python without the GIL.