Threads vs processes & the GIL

P32.threads-processes.01 · Audience: guest, it-ml, language-pro

Real LLM grading for this pageLLM grading (this page):

"Just add threads" is the most common way to not speed up a CPU-bound Python program. This module explains why — the Global Interpreter Lock — and then makes the difference between threads and processes concrete by looking at process IDs.

Step 1 / 4The GIL in one sentence
ⓘ Concept: One lock, one running thread
CPython protects its internals with a single Global Interpreter Lock. Only the thread holding it runs Python bytecode, so at any instant one thread is executing Python — no matter how many cores you have. Threads take turns; they do not run Python code simultaneously.

Why it matters — If you believe threads run Python in parallel, every CPU-bound 'optimisation' you write with them will disappoint you — and you won't know why.

Ask the mentor about this module

Ask a question about this content. The mentor explains and grounds its answer in what you are studying; asking is recorded as a learning signal, not a grade.

Ctrl/Cmd + Enter to send

🎓 Practice ladder

2 graded rungs · ~20 min

First argue the choice in an interview-style prompt, then prove the thread/process distinction with real process IDs (kernel runtime).

Rung 1 — predict the winner (interview)

Loading exercise…

Rung 2 — threads share a PID; processes don't (kernel)

Loading exercise…

Once you can say why a CPU-bound loop needs processes and an I/O-bound one is happy with threads, the rest of concurrency is mechanics — which the next module turns into concurrent.futures.