Flashcards

• What it is: A mutex in CPython that ensures only one thread executes Python bytecode at any instant, even on multi-core hardware.
• Why it exists: CPython's memory model (reference counting) is not thread-safe. The GIL was the pragmatic solution to prevent race conditions on ob_refcnt without per-object locking overhead.
• CPU-bound threads: Two Python threads running pure Python on an 8-core machine still only use 1 core. Parallelism is an illusion — threads take turns releasing and re-acquiring the GIL every sys.getswitchinterval() seconds (default 5ms).
• I/O-bound threads: The GIL IS released during blocking syscalls (network, file, sleep). This makes threading viable for I/O-heavy workloads like a market data consumer.
• C extensions: NumPy, pandas, and most scientific libraries explicitly release the GIL (Py_BEGIN_ALLOW_THREADS) during heavy computation — this is why numpy matrix ops scale.
• Workarounds in order of preference: multiprocessing (separate processes, own GIL), concurrent.futures.ProcessPoolExecutor, Cython/C extensions with nogil, or move to PyPy/GraalPy.
• Python 3.13+: Experimental "free-threaded" mode (--disable-gil) allows true multi-core threading but is not production-stable yet.
• Hedge fund context: A tick processing engine written in pure Python won't parallelise with threads. Use multiprocessing per strategy or push hot loops to Numba/Cython.

import threading, time, sys

# Confirm GIL switch interval
print(sys.getswitchinterval())  # 0.005 (5ms)

# CPU-bound: threads don't help
def count(n):
    while n > 0: n -= 1

t1 = threading.Thread(target=count, args=(10**7,))
t2 = threading.Thread(target=count, args=(10**7,))
start = time.perf_counter()
t1.start(); t2.start()
t1.join(); t2.join()
print(f"Threaded: {time.perf_counter()-start:.2f}s")
# Almost same as sequential — GIL serialises both threads

# Fix: ProcessPoolExecutor for CPU-bound
from concurrent.futures import ProcessPoolExecutor
with ProcessPoolExecutor() as ex:
    futures = [ex.submit(count, 10**7) for _ in range(2)]
    [f.result() for f in futures]
# ~2x faster on 2 cores