Recap — The GIL and Picking the Right Primitive

# The GIL and Picking the Right Primitive Python has three concurrency tools: threading, multiprocessing, asyncio. The right choice depends on the workload. Knowing the GIL helps. ## The GIL (Global Interpreter Lock) CPython has a global lock: only one thread can execute Python bytecode at a time. Implications: - Multi-threaded Python doesn't actually run in parallel for CPU work. - Threads share memory; switching is cheap. - I/O operations release the GIL (so threads ARE useful for I/O concurrency). The GIL exists because reference counting (Python's memory management) isn't thread-safe without it. In 2026, Python 3.13 added "free-threaded mode" (no-GIL): experimental, opt-in. Major libraries are slowly becoming compatible. Mainstream by ~2027-2028. ## Threading Multiple threads in one process. Share memory. GIL limits CPU parallelism but not I/O. ```python from concurrent.futures import ThreadPoolExecutor def fetch_url(url): return requests.get(url).text urls = [...] with ThreadPoolExecutor(max_workers=10) as executor: results = list(executor.map(fetch_url, urls)) ``` Use when: - I/O-bound + you're stuck with sync libraries (can't use asyncio). - Few hundred concurrent operations. - Need shared mutable state across workers (use locks carefully). Don't use when: - CPU-bound (GIL prevents parallelism). - Massive concurrency (1000+ threads → expensive context switching). - You can use asyncio instead (better for I/O). ## Multiprocessing Multiple processes, each with its own Python interpreter. No shared GIL. True parallelism. ```python from concurrent.futures import ProcessPoolExecutor def heavy_compute(x): return sum(i * i for i in range(x)) with ProcessPoolExecutor(max_workers=8) as executor: results = list(executor.map(heavy_compute, [10**6] * 10)) ``` Use when: - CPU-bound work (number crunching, image processing). - You have multiple cores. - Workers don't need shared state (or can share via queues). Don't use when: - I/O-bound (overhead exceeds benefit). - Small per-task work (process startup cost dominates). - Sharing large data is needed (serialization overhead). ### Multiprocessing gotchas - **Each process has its own memory.** No shared state by default. Use queues, pipes, or shared memory. - **Functions must be picklable.** Lambdas, closures fail. - **Process startup is expensive** (~50ms each). For many tiny tasks, threading wins. ## asyncio Single-threaded concurrency for I/O. Already covered. ## The decision matrix | Workload | Primitive | |---|---| | CPU-bound, multi-core | multiprocessing | | I/O-bound, async-friendly | asyncio | | I/O-bound, only sync libs available | threading | | Mix CPU + I/O | combine (asyncio + asyncio.to_thread for sync I/O; multiprocessing for CPU) | | GUI / interactive | asyncio (often) or threading | | Tiny number of tasks (<10) | sync; concurrency overhead not worth it | ## Combining primitives Real systems often mix: ```python # I/O-bound (async): fetch many URLs concurrently # CPU-bound (process pool): heavy parsing of results import asyncio from concurrent.futures import ProcessPoolExecutor async def fetch_and_parse(url, pool, loop): text = await fetch(url) parsed = await loop.run_in_executor(pool, heavy_parse, text) return parsed async def main(): loop = asyncio.get_event_loop() with ProcessPoolExecutor() as pool: results = await asyncio.gather(*[ fetch_and_parse(url, pool, loop) for url in urls ]) ``` asyncio for the I/O concurrency; process pool for the CPU work. ## Sharing state ### Threading (shared memory + locks) ```python import threading counter = 0 lock = threading.Lock() def increment(): global counter with lock: counter += 1 ``` Easy to share; dangerous if you forget locks (race conditions). ### Multiprocessing (queues / shared types) ```python from multiprocessing import Queue, Manager queue = Queue() def worker(q): q.put("result") # Or via Manager for dict/list: with Manager() as mgr: shared_dict = mgr.dict() ``` Higher overhead but no race conditions on shared memory (each process has its own). ### asyncio (no real sharing needed) Single thread; no race conditions for in-process state. For external coordination: locks, queues are async-aware versions. ## Python 3.13 free-threaded mode Python 3.13 (released Oct 2024) shipped experimental no-GIL build. In 3.13t and 3.14t: - Threads run truly in parallel (CPU work scales). - ~10-15% single-thread slowdown (cost of disabling GIL). - Some C extensions need updates. By 2027-2028: likely default. Today: experimental for adventurous teams. ## Common concurrency mistakes 1. **Threading for CPU work.** GIL prevents speedup; complexity for nothing. 2. **Multiprocessing for I/O.** Process startup overhead exceeds benefit. 3. **Async without async libraries.** Sync requests inside async = bottleneck. 4. **Race conditions in threading.** Shared mutable state without locks. 5. **P