Developers on Red Hat Enterprise Linux 9.8 and 10.2 can now test full parallel CPU execution in Python using the new free-threaded Python 3.14 build. In addition to the regular Python 3.14 interpreter, we also provide the free-threaded variant in the Red Hat CodeReady Linux Builder repositories.
Python 3.14 is the first upstream release where the free-threaded build is officially supported rather than experimental.
Threading Python without the GIL: What is free-threaded Python?
The standard CPython interpreter uses the Global Interpreter Lock, usually called the GIL. The GIL prevents multiple Python threads from executing Python bytecode at the same time in one process. While the GIL simplifies CPython internal memory management, it prevents CPU-bound Python code from utilizing multiple CPU cores through threads.
The free-threaded build removes this limitation. It is built with the GIL disabled and allows Python threads to execute in parallel on multiple CPU cores. This can improve performance for programs that are already designed around threading, especially CPU-bound workloads where multiprocessing is too expensive or too complicated.
This does not mean that every Python program will become faster automatically. I/O-bound applications, single-threaded programs, and applications limited by external services might see little or no benefit. But for workloads where threads do real CPU work, free-threaded Python allows CPU-bound Python threads to execute across multiple cores in a single process.
How to install it
The free-threaded Python 3.14 interpreter is available as the python3.14-freethreading package. It installs the python3.14t executable, so it can be installed next to other Python interpreters without replacing the system Python.
Enable the CodeReady Linux Builder repository:
sudo subscription-manager repos \
--enable codeready-builder-for-rhel-$(rpm -E '%{rhel}')-$(uname -m)-rpmsThen install the interpreter:
sudo dnf install python3.14-freethreadingRun it with:
python3.14tYou can verify that the interpreter supports free-threading with:
python3.14t -VVThe output should mention that this is a free-threading build. You can also check from Python code:
python3.14t -c "import sys, sysconfig; print(sysconfig.get_config_var('Py_GIL_DISABLED')); print(sys._is_gil_enabled())"The first value tells you whether the interpreter was built with free-threading support. The second tells you whether the GIL is currently enabled in this process.
Running existing code
If your pure Python code doesn't share state across threads, it will likely run without changes. But if your application implicitly relied on the GIL for thread safety, real race conditions can surface.
Built-in container types like dict, list, and set use internal locks in the free-threaded build to protect individual operations, similar to the protection the GIL provided. However, sequences of operations are not atomic. For example, checking whether a key exists in a dictionary and then setting it are two separate operations, and another thread can modify the dictionary in between. If your code relies on multiple operations being performed without interleaving, use threading.Lock, queues, or another explicit synchronization mechanism.
Extension modules need more attention. Some third-party packages, especially packages with C extensions, might not yet support free-threaded Python. When such a module is imported, Python can enable the GIL again for the process. This keeps compatibility, but it also means that the application no longer gets the full benefit of free-threaded execution. If you know your workload is safe, you can override this with PYTHON_GIL=0 or -Xgil=0 to keep the GIL disabled, but this is at your own risk.
For this reason, the best first step is to test your application and its dependencies with python3.14t, run your test suite, and measure the workload that matters to you.
When can you benefit?
Free-threaded Python is most beneficial when your application already uses threads, performs CPU work in Python, and would benefit from using several CPU cores within a single process.
Good candidates include data processing pipelines, simulation code, CPU-heavy background workers, local parallel processing, and applications where sharing Python objects between workers is easier than using separate processes.
Applications that mostly wait for the network, database, disk, or external APIs might not benefit much. For those workloads, the regular Python build, asynchronous I/O, or existing worker models can still be the better choice.
The free-threaded build has a small single-threaded performance overhead, currently around 5%-10% compared to the regular build.
What this means for developers
Free-threaded Python does not remove the need to design concurrent code carefully. Instead, it makes correctly threaded code more useful.
When developing code that should work well on both regular and free-threaded Python, keep these recommendations in mind:
- Use explicit synchronization for shared mutable state.
- Test multi-threaded execution under
python3.14t. - Verify whether your dependencies support free-threading.
- Measure performance before changing architecture.
The regular Python interpreter remains the default and the right choice for many workloads. The free-threaded build gives developers a new option where threads, shared memory, and multicore CPU usage are a good fit.
Install python3.14-freethreading on RHEL 9.8 or 10.2 today, run your test suite against python3.14t, and prepare your applications for the next stage of Python concurrency.
