Try Free Threading: The Future of Parallel Processing in Python

For several years now, there has been significant effort to make the Global Interpreter Lock optional in CPython. (CPython built with the global interpreter lock disabled is called a “free-threaded” build.) This represents a huge change for the Python community that will take several years to fully test and support across the many thousands of popular Python projects. We at Anaconda think this is absolutely critical for the future of Python, so we want to support and amplify community efforts to test and update Python projects to work well with free-threaded Python.

What is the Global Interpreter Lock and what problem did it solve?

The Global Interpreter Lock (GIL) was introduced a long time ago to CPython to allow the interpreter to safely work with multiple threads. The “global” in Global Interpreter Lock means that there is one lock for the entire interpreter. This makes locking simple and fast. However, a global lock ensures only one thread can be executing Python code at any given time, and threads will then take turns running in the interpreter. Threads that are waiting for I/O or running external compiled code (which is very common in packages like NumPy, PyTorch, etc) can release the GIL and allow other Python threads to run, but only one of those threads will make progress at any given time.

With the GIL, the execution timeline of a multithreaded Python program can look like this:

In a world with computers that have dozens of CPU cores, this is a huge limitation. Python users have had to either start multiple processes, which creates memory and communication overhead, or move parallel code to Python extensions implemented in non-Python languages that can release the GIL during execution.

What is free-threading?

Free-threaded builds of CPython 3.13 replace the single global lock that applies to the whole interpreter with many finer-grained locks that protect different parts of the interpreter separately. The result is that Python threads should be able to execute concurrently without interfering with each other if they are working with distinct objects. When threads do need to communicate, they can safely do so with standard mechanisms like in-memory queues and locks, and not have the overhead of needing to pickle objects and send them to other processes, or even more complex techniques. Ideally, free-threading should be basically invisible to the Python developer, other than threaded Python programs will be able to use more CPU cores at once and finish execution faster. In this new world, the execution timeline of the previously shown multithreaded Python program shrinks down to this:

This is a very exciting improvement, as it has the potential to enable Python applications to take advantage of multi-core CPUs with much less effort and overhead than current methods.

How do I try it out?

Free-threading requires significant changes to the Python interpreter itself. The first version of Python with free-threading support will be Python 3.13, which will be released in October 2024. Free-threading is a build-time option, and will be disabled by default to give the Python community time to add support and test the feature further. Additionally, compiled Python extensions need to be recompiled to work with the free-threading interpreter, even if there are no other source code changes needed. This will require projects that want to support both the regular Python 3.13 build and the free-threading build to publish two different wheels.

In the meantime, Anaconda is building an experimental set of conda packages with free-threading enabled to help the community test their code. You can create a Python 3.13 environment with free-threading on Linux x86-64 and macOS ARM64 systems by running the command:

conda create -n py313t -c ad-testing/label/py313 python-freethreading
conda activate py313t

Note that python-freethreading is an empty metapackage that installs the free-threading build of the python package. These packages depend on a special python_abi package in order to ensure that ABI-incompatible packages are not mixed together. You will need to include the -c ad-testing/label/py313 option to conda whenever installing or updating packages in the environment. We have a limited selection of packages in the channel, so please let us know if there are others you would like to test!

Feel free to use this forum for asking general questions about free-threading, getting help on how to make your code compatible with free-threading, and reporting issues you run into while testing the free-threading conda packages. There is also an excellent community site tracking progress on free-threading support in popular Scientific Python packages at py-free-threading.github.io. Be sure to tag your posts in the Anaconda Community forum with the free_threading tag so they are easier to find. Thanks!

2 Likes