The GIL — Global Interpreter Lock

JavaScript is single-threaded — Python has threads, but with a catch

As a TypeScript developer, you are used to JavaScript’s concurrency model: one thread, one event loop, non-blocking I/O via callbacks and async/await. There are no data races because there is only ever one piece of JavaScript code running at a time. Worker threads exist, but they share no memory by default — they communicate via message passing.

Python has true OS threads via the threading module. You can spawn multiple threads and they run in the same process with shared memory. However, CPython (the reference Python implementation) includes a mechanism called the Global Interpreter Lock that fundamentally limits what those threads can do in parallel. Understanding the GIL is essential for writing Python programs that need to scale across CPU cores.

What the GIL is

The GIL is a mutex — a mutual exclusion lock — that protects CPython’s internal state. CPython’s memory management (reference counting for garbage collection) is not thread-safe. Rather than add fine-grained locks throughout the interpreter, Guido van Rossum’s team added one coarse lock: only one thread may execute Python bytecode at any given moment.

Threads do take turns — the GIL is released and re-acquired periodically (roughly every 5ms in Python 3.2+, or whenever a thread makes an I/O system call). But for pure CPU work, having two threads does not give you two CPU cores of throughput. One thread runs; the other waits.

TypeScript

// TypeScript/Node.js: worker_threads for CPU parallelism
// Workers share no memory by default — communicate with postMessage
import { Worker, isMainThread, parentPort } from 'worker_threads';

if (isMainThread) {
  const worker = new Worker(__filename);
  worker.on('message', (result) => {
    console.log('result from worker:', result);
  });
  worker.postMessage({ start: 0, end: 1_000_000 });
} else {
  parentPort?.on('message', ({ start, end }) => {
    let sum = 0;
    for (let i = start; i < end; i++) sum += i;
    parentPort?.postMessage(sum);
  });
}

Python

# Python: threads exist but the GIL limits CPU parallelism
import threading

results = []

def cpu_sum(start, end, out, index):
    total = sum(range(start, end))
    out[index] = total

# Two threads — but only one runs Python bytecode at a time
t1 = threading.Thread(target=cpu_sum, args=(0, 500_000, results, 0))
t2 = threading.Thread(target=cpu_sum, args=(500_000, 1_000_000, results, 1))
results = [None, None]

t1.start(); t2.start()
t1.join();  t2.join()

print(sum(results))  # correct answer, but not 2x faster

When the GIL hurts and when it does not

The GIL only blocks concurrent execution of Python bytecode. Many operations that appear to be Python code actually drop into C extensions or the OS, and those can release the GIL voluntarily:

Workload	GIL effect	Recommended tool
CPU-bound Python loops	Blocks parallelism	multiprocessing or C extensions
Network I/O (requests, sockets)	GIL released during syscall	threading or asyncio
File I/O	GIL released during syscall	threading or asyncio
NumPy / pandas operations	GIL released in C layer	threading is fine
Subprocess calls	GIL released	threading is fine

The practical rule: if your bottleneck is the Python interpreter executing your code, threads will not help — use multiprocessing. If your bottleneck is waiting on external systems (network, disk, databases), threads or asyncio work well.

Bypassing the GIL with multiprocessing

multiprocessing spawns separate Python interpreter processes — each with its own GIL and its own CPU core. It is the standard tool for CPU-bound parallelism.

TypeScript

// TypeScript: CPU parallelism via worker_threads pool
import { Worker } from "worker_threads";
import * as os from "os";

function runWorker(data: number): Promise<number> {
  return new Promise((resolve, reject) => {
    const w = new Worker(`
      const { parentPort, workerData } = require("worker_threads");
      let total = 0;
      for (let i = 0; i < workerData; i++) total += i;
      parentPort.postMessage(total);
    `, { eval: true, workerData: data });
    w.on("message", resolve);
    w.on("error", reject);
  });
}

const cpus = os.cpus().length;
Promise.all(Array.from({ length: cpus }, (_, i) =>
  runWorker(1_000_000 / cpus)
)).then(results => console.log(results.reduce((a, b) => a + b, 0)));

Python

# Python: multiprocessing bypasses the GIL entirely
from multiprocessing import Pool
import os

def cpu_work(n):
    return sum(range(n))

if __name__ == "__main__":
    cpus = os.cpu_count()
    chunk = 1_000_000 // cpus
    with Pool(cpus) as pool:
        results = pool.map(cpu_work, [chunk] * cpus)
    print(sum(results))

Free-threaded Python is official (3.14)

Python 3.13 shipped the GIL-free build as an experiment (PEP 703, python3.13t). Python 3.14 promoted it to an officially supported build (PEP 779): still a separate interpreter, python3.14t, and still not the default — but no longer experimental. In that build, threads genuinely run Python bytecode on several cores at once.

The trade-off is real: reference counting uses atomic operations, so single-threaded code runs roughly 5–10% slower, and C extensions that quietly relied on the GIL have to be audited and rebuilt. Check which build you are on with sys._is_gil_enabled().

Python 3.14 also adds concurrent.interpreters (PEP 734) — multiple interpreters inside one process, each with its own GIL, plus an InterpreterPoolExecutor that plugs into the concurrent.futures API. It sits between threads (shared memory, one GIL) and processes (no shared memory, slow to start), which makes it the closest thing Python has to Node’s worker_threads.

Playground note: Demonstrating GIL effects requires comparing CPU-bound vs I/O-bound thread timing, which is not meaningful in a browser sandbox. Run the examples locally with python3 -c "import threading; ...".

🟦 Bypassing the GIL: multiprocessing, asyncio, and C extensions

multiprocessing

The multiprocessing module spawns separate Python interpreter processes. Each process has its own GIL, its own memory space, and runs on its own CPU core independently. Data is exchanged through Queue, Pipe, or shared memory (multiprocessing.shared_memory). This is the standard solution for CPU-bound parallelism in Python:

from multiprocessing import Pool

def cpu_task(n):
    return sum(range(n))

with Pool(processes=4) as pool:
    results = pool.map(cpu_task, [1_000_000] * 4)
print(results)

The downside: process startup overhead is higher than thread startup, and sharing state requires explicit serialization (pickling).

asyncio: cooperative, not preemptive

asyncio is Python’s event loop for I/O-bound concurrency. It runs entirely in a single thread — no GIL interaction at all. Like JavaScript’s event loop, it uses cooperative multitasking: a coroutine explicitly yields control with await, which lets the event loop run another coroutine. There is no preemption and no data races on Python objects.

import asyncio

async def fetch(url):
    await asyncio.sleep(1)  # simulates an I/O wait
    return f"result from {url}"

async def main():
    tasks = [fetch("url1"), fetch("url2"), fetch("url3")]
    results = await asyncio.gather(*tasks)
    print(results)  # all three complete in ~1 second

asyncio.run(main())

asyncio and threading solve the same I/O-bound problem. asyncio has lower overhead per concurrent task and is better when you have thousands of connections; threading is simpler for small numbers of long-lived blocking calls.

C extensions and Cython

C extension modules can call Py_BEGIN_ALLOW_THREADS to release the GIL, do CPU work in C (which runs on multiple cores simultaneously with Python threads), and then reacquire it with Py_END_ALLOW_THREADS. NumPy, pandas, and most scientific Python libraries do exactly this, which is why NumPy operations are safe to parallelize with threads even though they look like Python code.

Cython, a Python superset that compiles to C, lets you annotate functions with with nogil: to release the GIL for a block of C-level code. This is a common pattern in high-performance Python libraries.

concurrent.futures: a uniform API

concurrent.futures gives ThreadPoolExecutor and ProcessPoolExecutor the same interface, so switching between threads (I/O-bound) and processes (CPU-bound) is a one-line change:

from concurrent.futures import ThreadPoolExecutor, ProcessPoolExecutor

# I/O-bound: use threads
with ThreadPoolExecutor(max_workers=10) as executor:
    futures = [executor.submit(fetch_url, url) for url in urls]
    results = [f.result() for f in futures]

# CPU-bound: use processes
with ProcessPoolExecutor() as executor:
    results = list(executor.map(cpu_intensive, data_chunks))

What does the GIL prevent in CPython?

More than one Python process from running at the same time More than one Python thread from executing Python bytecode simultaneously asyncio coroutines from running concurrently C extension modules from using multiple CPU cores

For which type of workload does the GIL cause the most harm?

I/O-bound tasks like network requests CPU-bound tasks implemented in pure Python File reads and writes Database queries

What Python module is the standard solution for true CPU parallelism across multiple cores?

threading asyncio concurrent.futures with ThreadPoolExecutor multiprocessing

How does asyncio achieve concurrency without threads?

It uses OS-level preemptive scheduling It runs one coroutine per CPU core It uses cooperative multitasking: coroutines yield control explicitly with await It releases the GIL automatically for all async functions

Submit

Mark as complete