Python GIL — CPU Below 15% on 16 Cores

Native GIL detection: Python 3.2+ exposes sys.getswitchinterval() (default 5ms). You can lower it to make threads switch more often, but that increases overhead. Instead, measure the number of GIL acquisitions per second using perf stat -e syscalls:sys_enter_futex.

Micro-benchmark pattern: Run a CPU-bound loop (pure Python) with 1 thread, then N threads. If time grows linearly with N, the GIL is fully serializing.

import os
import sys

def check_gil_contention(pid):
    path = f'/proc/{pid}/status'
    if not os.path.exists(path):
        print("Can't check — not on Linux or no /proc")
        return
    with open(path) as f:
        for line in f:
            if 'voluntary_ctxt_switches' in line:
                _, val = line.split(':')
                val = int(val.strip())
                if val > 10000:
                    print(f"HIGH context switches ({val}/sec) — GIL contention likely")
                else:
                    print(f"Low context switches ({val}) — GIL not a problem")

Beating the GIL: Threading, Multiprocessing, asyncio

Three main strategies to work around (or avoid) the GIL:

Multiprocessing — The most common approach. Each Python process has its own GIL, so N processes give you nearly Nx speedup for CPU-bound work. Use concurrent.futures.ProcessPoolExecutor or multiprocessing.Pool. Downside: overhead of serializing data between processes via pickle. If you pass large data structures, that can dominate runtime.

asyncio — Cooperative multitasking with a single thread. No GIL contention because there's only one thread. Great for I/O-bound workloads that spend most time waiting. Use await for all I/O. Downside: all code must be async — can't easily integrate blocking calls.

C Extensions with nogil — Write performance-critical code in Cython or C and release the GIL explicitly. The with nogil: block in Cython runs without the GIL, giving true parallelism. Downside: complexity, C interop.

Which to pick? - I/O-bound, many concurrent tasks → asyncio (single thread, no GIL fight) - CPU-bound, pure Python → multiprocessing - CPU-bound, mostly C extensions → threading may work (if ext releases GIL) - Mixed workload → multiprocessing for CPU parts, thread pool for I/O parts

The choice also depends on overhead tolerance. For small tasks (millisecond computation), multiprocessing overhead (process spawn, pickle) often outweighs parallel speedup. Profile before committing.

import time
from concurrent.futures import ProcessPoolExecutor, ThreadPoolExecutor

def cpu_task(n):
    """Simulate CPU work."""
    sum([i**2 for i in range(n)])
    return n

N_WORKERS = 8
TASKS = [10_000_000] * N_WORKERS

# Threads
start = time.time()
with ThreadPoolExecutor(max_workers=N_WORKERS) as ex:
    list(ex.map(cpu_task, TASKS))
thread_time = time.time() - start

# Processes
start = time.time()
with ProcessPoolExecutor(max_workers=N_WORKERS) as ex:
    list(ex.map(cpu_task, TASKS))
proc_time = time.time() - start

print(f"Threads: {thread_time:.2f}s — no speedup")
print(f"Processes: {proc_time:.2f}s — ~{N_WORKERS}x speedup")

Python 3.13 'Free-threading' (No-GIL) Status

PEP 703 introduced an experimental free-threaded build of CPython 3.13 that removes the GIL entirely. Instead of a single global lock, it uses per-object reference counting with atomic operations and deferred memory deallocation. This allows true multi-core parallelism for pure Python CPU-bound code without switching to multiprocessing.

How to enable: Build CPython with --disable-gil or use a pre-built free-threaded package (e.g., python3.13t on conda-forge). At runtime, sys._is_gil_enabled() returns False.

Current limitations: - Not production-ready — many C extensions assume the GIL protects them and will crash or corrupt data. - Single-threaded overhead of 5–15% due to atomic operations. - The Python C API has new requirements (e.g., PyThreadState_EnterTracing must be used correctly). - Only a subset of popular packages are compatible (numpy, pandas, pyarrow).

When to test it: If you have CPU-bound pure Python code that cannot be moved to C or multiprocessing (e.g., dynamic code generation, complex business logic), try free-threaded Python in a staging environment. But do not deploy to production until Python 3.14 or later when the feature stabilizes.

The free-threaded build is a glimpse of Python's future — eventually the GIL will be optional by default, and you'll get parallelism for free.

Python 3.13: The No-GIL Build (Free-Threaded Python)

Python 3.13 introduced an experimental build configuration called "free-threaded" that removes the GIL entirely. This is the result of PEP 703 ("Making the Global Interpreter Lock Optional") and years of work to make CPython's memory management thread-safe without a global lock.

How it works: Instead of one lock for all objects, CPython now uses per-object reference counting with atomic operations, plus a deferred reference counting approach for object deallocation. The GIL is eliminated.

Current status (2026): It's still experimental. Activate with --disable-gil at build time. Not all C extensions are compatible — those that assume the GIL protects them will crash. Known working: numpy, pandas, pyarrow. Known incompatible: many Cython extensions, lxml, some database drivers.

Performance: For pure Python CPU-bound code, free-threaded Python can achieve near-linear scaling on multi-core machines. But single-threaded performance is slightly worse (5-15% overhead) due to atomic operations in reference counting.

Production readiness: Not yet. Unless you control every C extension in your stack, stay with the GIL-py for now. But this is the future — Python will eventually make the GIL optional by default.

Why a Single Global Lock Instead of Per-Object Mutexes?

You just saw the race condition in list.append. Any sane C developer would slap a per-object mutex on it and move on. Python didn't. Why?

Performance. Pure and simple. In the early 90s, when Guido van Rossum wrote CPython, computers had one core. Threading was for I/O concurrency, not CPU parallelism. Adding a mutex to every single object operation — every attribute access, every dict lookup, every list append — would have killed single-threaded performance dead. Each mutex acquire/release costs tens of nanoseconds. That adds up fast when you're doing millions of operations per second.

The GIL is one lock, held for the duration of a bytecode instruction or a short C call. No lock contention in single-threaded code. No cascading lock overhead on every object. It was a pragmatic trade-off: sacrifice multi-core parallelism (which didn't exist yet) for single-threaded speed (which mattered).

And it worked. CPython became the reference implementation, and the GIL baked itself into the language's DNA. By the time multi-core CPUs became standard, the GIL was a core assumption in every C extension, every internal data structure, every thread-unsafe optimization. Removing it would mean rebuilding the whole interpreter.

// io.thecodeforge — python tutorial

import threading
import time


def hammer_list(count):
    """Append to a local list in a tight loop."""
    data = []
    for i in range(count):
        data.append(i)
    return data


if __name__ == "__main__":
    N = 5_000_000
    start = time.perf_counter()
    hammer_list(N)
    single_time = time.perf_counter() - start

    # Simulate the cost: two threads holding the GIL
    t1 = threading.Thread(target=hammer_list, args=(N,))
    t2 = threading.Thread(target=hammer_list, args=(N,))
    start = time.perf_counter()
    t1.start()
    t2.start()
    t1.join()
    t2.join()
    concurrent_time = time.perf_counter() - start

    print(f"Single-threaded:  {single_time:.3f}s")
    print(f"Two threads:     {concurrent_time:.3f}s")
    print(f"Overhead factor: {concurrent_time / single_time:.2f}x")

How Python 3.13 Finally Breaks the Curse (Without Breaking Your Code)

The No-GIL build in Python 3.13 is not a flag you flip. It's a completely separate build of CPython — --disable-gil — that ships alongside the regular GIL'd interpreter. You opt in per interpreter binary, not per script. This avoids a thousand C extensions suddenly catching fire.

The trick? They didn't remove the GIL and hope for the best. They added per-object locks — exactly what the original CPython skipped. But now, those locks are fine-grained: one lock per PyObject, not one lock per interpreter. The list.append race condition? Now it's protected by a per-list mutex, acquired only when the internal state actually changes.

But here's the rub: every C extension ever written assumed the GIL protected it. numpy, pandas, scipy — they all call internal C APIs that mutate shared state without locking. The No-GIL build wraps every single C API call in a global lock equivalent to the old GIL. Result: extensions run, but with zero parallelism gains. You only get the speedup if your code is pure Python or written explicitly for free-threaded mode.

It's a bridge. You can compile your existing code with the No-GIL interpreter today, verify it doesn't crash, and then incrementally migrate hot paths to lock-free or per-object-locked patterns. No rewrite from scratch. That's the real engineering win.

// io.thecodeforge — python tutorial

import sys
import time
from concurrent.futures import ThreadPoolExecutor


def digest_vector(n):
    """Pure Python CPU-bound work: float ops."""
    total = 0.0
    for i in range(n):
        total += (i * 1.0001) ** 0.5
    return total


if __name__ == "__main__":
    N = 5_000_000
    WORKERS = 4

    print(f"Python: {sys.version.split()[0]}")
    print(f"Free-threaded: {bool(sys.implementation._feature_flags & 2)}")

    with ThreadPoolExecutor(max_workers=WORKERS) as pool:
        start = time.perf_counter()
        futures = [pool.submit(digest_vector, N) for _ in range(WORKERS)]
        results = [f.result() for f in futures]
        elapsed = time.perf_counter() - start

    print(f"{WORKERS} workers, {N:,} iterations each: {elapsed:.3f}s")

Why fork() and the GIL Are a Toxic Combination

You're running a web server. You fork() to handle requests. Suddenly, your workers deadlock or crash. The root cause? The GIL doesn't protect you from POSIX fork() semantics.

When fork() executes, the child process inherits a copy of the parent's memory, including mutexes and locks. But the GIL is a mutex. If the parent held the GIL at the exact moment of fork, the child now has a locked GIL with no thread to unlock it. Any Python thread trying to acquire the GIL in the child process blocks forever. This is a classic deadlock that wastes hours of debugging.

The fix is brutal and simple: immediately after fork(), call PyOS_AfterFork_Child() (Python 3.7+) or reinitialize threading in the child. Even better: use multiprocessing with spawn (not fork) on macOS/Windows. For production Python, never assume fork()+threads works. It doesn't. Measure your process-start method, or you'll measure a production outage.

// io.thecodeforge — python tutorial

import os
import threading
import time

def show_deadlock():
    lock = threading.Lock()
    lock.acquire()

    pid = os.fork()
    if pid == 0:
        # Child: lock is acquired in parent
        # No thread will ever release it
        print("Child: trying to acquire GIL-level lock...")
        try:
            lock.acquire(timeout=1)  # Guaranteed timeout
        except:
            print("Child: deadlocked as expected")
        os._exit(1)
    else:
        os.wait()
        print("Parent: done")

if __name__ == "__main__":
    show_deadlock()

Mastering the Legacy API: sys.setswitchinterval() for GIL Control

Most devs treat the GIL as a black box. But Python exposes a legacy API that directly controls how often the GIL switches threads: sys.setswitchinterval(). This is your throttle for CPU-bound thread interleaving.

The switch interval (default 5ms in Python 3.2+) determines how long a thread holds the GIL before voluntarily yielding. Lower it to 1ms for more responsive interleaving (better for UI threads). Raise it to 100ms to reduce context-switch overhead in pure CPU work. This is not a hack—it's a documented tool. But it's global. Every thread in your process pays the cost.

Why does this matter in production? If you run CPU-bound tasks with threading, a high switchinterval starves I/O threads. A low one burns CPU on context switches. Profile your workload. For async or multiprocessing, this API is irrelevant—you've already beaten the GIL. But for legacy threaded systems, it's your only lever. Use it, or your production latency charts will mock you.

// io.thecodeforge — python tutorial

import sys
import time
import threading

def cpu_burn():
    start = time.perf_counter()
    for _ in range(10_000_000):
        _ = 2 ** 10
    elapsed = time.perf_counter() - start
    print(f"Thread done in {elapsed:.3f}s")

# Default: 5ms
sys.setswitchinterval(0.001)  # 1ms — aggressive yielding

threads = [threading.Thread(target=cpu_burn) for _ in range(4)]
for t in threads:
    t.start()
for t in threads:
    t.join()

print(f"Final switch interval: {sys.getswitchinterval()}s")

Why Hasn’t the GIL Been Removed Yet?

The GIL persists because removing it breaks C extensions that dominate Python’s ecosystem. Libraries like NumPy, pandas, and TensorFlow rely on the C API, which assumes single-threaded memory management via PyThreadState. A no-GIL build would require rewriting every C extension to use atomic operations or fine-grained locks—a years-long effort with no backward compatibility. Additionally, Python’s reference counting is fundamentally thread-unsafe without the GIL. Alternative garbage collectors (like tracing GC) exist, but they introduce unpredictable pauses, degrade cache performance, and increase memory overhead. The core dev team’s decision is pragmatic: ship stability now, chase parallelism later. Python 3.13’s free-threaded build exists as an experimental flag (--disable-gil), but the default build retains the GIL to protect the 90% of users who depend on C extensions. Removing the GIL isn’t a technical impossibility; it’s an ecosystem engineering challenge.

// io.thecodeforge — python tutorial

import sys

# Check if GIL is disabled (Python 3.13+)
def check_gil_status():
    if not hasattr(sys, 'getgil'):
        print("GIL: Present (default build)")
        return
    gil_enabled = sys.getgil()
    if gil_enabled:
        print("GIL: Present (free-threaded build auto-disabled?)")
    else:
        print("GIL: Disabled (free-threaded build active)")

check_gil_status()

Asynchronous Notifications

The GIL creates a hidden bottleneck for asynchronous notifications—signals, wake-up events, or inter-thread messages that must cross the GIL boundary. When a thread sends a notification (e.g., threading.Event.set()), it forces the GIL to schedule the receiving thread. Under heavy concurrency, this scheduling overhead dominates: the GIL’s switch interval (default 5ms) means a notification can take 5ms+ to deliver even if the event is ready. This kills real-time responsiveness. For I/O-bound systems like web servers, the fix is to avoid threads entirely: use asyncio with cooperative multitasking, which sidesteps the GIL by never holding it during await. Alternatively, use zero-copy inter-thread queues (collections.deque with manual scheduling hints) to minimize GIL acquisition. Python 3.13’s free-threaded build removes notification latency entirely, but at the cost of slower atomic operations. Measure your notification latency with time.perf_counter_ns() before optimizing.

// io.thecodeforge — python tutorial

import threading
import time

event = threading.Event()
latency = []

def waiter():
    while True:
        event.wait()
        t = time.perf_counter_ns() - last_set[0]
        latency.append(t)
        event.clear()

threading.Thread(target=waiter, daemon=True).start()

for _ in range(5):
    last_set = [time.perf_counter_ns()]
    event.set()
    time.sleep(0.001)

print(f"Avg notification latency: {sum(latency)//len(latency)} ns")

PEP 703: No-GIL Python (free-threaded builds)

PEP 703, titled "Making the Global Interpreter Lock Optional in CPython," is the foundational proposal for free-threaded Python builds. It introduces a mode where the GIL is disabled, allowing true parallel execution of threads on multiple CPU cores. The PEP outlines key changes: per-object reference counting with atomic operations, biased reference counting to reduce overhead for frequently accessed objects, and a deferred reference counting mechanism to handle cycles. Free-threaded builds are available as an experimental feature in Python 3.13, enabled via the --disable-gil configure flag. This section explains how to build and use free-threaded Python, and demonstrates its impact on CPU-bound tasks.

```python import threading import time

def cpu_intensive(n): count = 0 for i in range(n): count += i ** 2 return count

# Without GIL (free-threaded build), threads can run in parallel threads = [] start = time.time() for _ in range(4): t = threading.Thread(target=cpu_intensive, args=(10**7,)) threads.append(t) t.start() for t in threads: t.join() print(f"Time with free-threading: {time.time() - start:.2f}s") ```

This code runs four CPU-bound threads. On a standard CPython build, the GIL limits parallelism; on a free-threaded build, all four threads can execute simultaneously, potentially achieving near-linear speedup on a multi-core system.

import threading
import time

def cpu_intensive(n):
    count = 0
    for i in range(n):
        count += i ** 2
    return count

threads = []
start = time.time()
for _ in range(4):
    t = threading.Thread(target=cpu_intensive, args=(10**7,))
    threads.append(t)
    t.start()
for t in threads:
    t.join()
print(f"Time with free-threading: {time.time() - start:.2f}s")

GIL Removal: Current Status and Migration Impact

The removal of the GIL is a multi-year effort. Python 3.13 introduced free-threaded builds as an experimental feature, but the GIL remains the default. The Python Steering Council has accepted PEP 703, but full removal is targeted for Python 3.14 or later. This section covers the current status, migration impact, and how to prepare your codebase.

# Example: Thread-unsafe global counter (will break without GIL)
import threading
counter = 0
def increment():
    global counter
    for _ in range(100000):
        counter += 1  # Not atomic without GIL
threads = [threading.Thread(target=increment) for _ in range(4)]
for t in threads:
    t.start()
for t in threads:
    t.join()
print(f"Counter: {counter} (expected 400000)")

Without the GIL, the counter will likely be less than 400000 due to race conditions. Fix by using threading.Lock or atomic operations.

import threading

counter = 0
def increment():
    global counter
    for _ in range(100000):
        counter += 1

threads = [threading.Thread(target=increment) for _ in range(4)]
for t in threads:
    t.start()
for t in threads:
    t.join()
print(f"Counter: {counter} (expected 400000)")

GIL in C Extensions: Releasing the GIL Manually

C extensions can release the GIL during long-running operations to allow other Python threads to run. This is crucial for I/O-bound or computationally intensive C code that doesn't need Python object access. The Python C API provides Py_BEGIN_ALLOW_THREADS and Py_END_ALLOW_THREADS macros to temporarily release and reacquire the GIL. This section explains how to use these macros and best practices.

```c #include

static PyObject my_long_running_function(PyObject self, PyObject* args) { // Release the GIL Py_BEGIN_ALLOW_THREADS // Perform long-running operation (e.g., file I/O, computation) // Do NOT access Python objects here sleep(5); // Simulate work Py_END_ALLOW_THREADS // Reacquired GIL; safe to access Python objects return PyLong_FromLong(42); } ```

When the GIL is released, the thread cannot access Python objects or call Python C API functions. Any such access must be done before releasing or after reacquiring. This pattern is used in libraries like NumPy and Pillow to improve concurrency.

```python # Python code calling the C extension import my_extension import threading

def worker(): result = my_extension.my_long_running_function() print(result)

threads = [threading.Thread(target=worker) for _ in range(4)] for t in threads: t.start() for t in threads: t.join() ```

Without releasing the GIL, the four threads would execute sequentially. With manual release, they can run in parallel (assuming the C function doesn't hold the GIL).

#include <Python.h>

static PyObject* my_long_running_function(PyObject* self, PyObject* args) {
    Py_BEGIN_ALLOW_THREADS
    sleep(5);
    Py_END_ALLOW_THREADS
    return PyLong_FromLong(42);
}

static PyMethodDef methods[] = {
    {"my_long_running_function", my_long_running_function, METH_VARARGS, ""},
    {NULL, NULL, 0, NULL}
};

static struct PyModuleDef module = {
    PyModuleDef_HEAD_INIT, "my_extension", NULL, -1, methods
};

PyMODINIT_FUNC PyInit_my_extension(void) {
    return PyModule_Create(&module);
}