Multiprocessing and Parallelism

The Global Interpreter Lock (GIL) is a mutex in CPython that allows only one thread to execute Python bytecode at a time. This means threading.Thread does not provide CPU parallelism for pure Python code.

import threading

# These threads run SEQUENTIALLY due to the GIL:
t1 = threading.Thread(target=cpu_bound_func, args=(data1,))
t2 = threading.Thread(target=cpu_bound_func, args=(data2,))
t1.start(); t2.start()
t1.join(); t2.join()

The GIL is released during I/O operations and by C extensions (NumPy, SciPy), so threading works for I/O-bound and NumPy-heavy workloads.

multiprocessing.Pool spawns worker processes, each with its own Python interpreter and GIL. Work is distributed via:

from multiprocessing import Pool

def process_chunk(data):
    return heavy_computation(data)

with Pool(processes=4) as pool:
    results = pool.map(process_chunk, data_chunks)

Data is serialized (pickled) to send to workers and deserialized on return. This serialization overhead makes Pool inefficient for small tasks or large data transfers.

concurrent.futures provides a high-level API with two executors:

from concurrent.futures import ProcessPoolExecutor, ThreadPoolExecutor

# CPU-bound: use processes
with ProcessPoolExecutor(max_workers=4) as exe:
    futures = [exe.submit(compute, chunk) for chunk in chunks]
    results = [f.result() for f in futures]

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

The Future object provides .result(), .done(), .cancel(), and supports as_completed() for processing results as they arrive.

joblib.Parallel provides a concise syntax for parallelizing loops, with automatic backend selection and memory mapping for large arrays:

from joblib import Parallel, delayed

results = Parallel(n_jobs=4, backend='loky')(
    delayed(process)(item) for item in data
)

joblib's loky backend handles process management more robustly than multiprocessing.Pool, with better error reporting and automatic cleanup.

Amdahl's Law gives the theoretical maximum speedup when parallelizing a program with serial fraction $f_s$:

$$S_p = \frac{1}{f_s + \frac{1-f_s}{p}}$$

where $p$ is the number of parallel workers. As $p \to \infty$:

$$S_{\infty} = \frac{1}{f_s}$$

If 10% of your code is serial ($f_s = 0.1$), the maximum possible speedup is $10\times$, regardless of how many cores you have.