Threads, Processes and the GIL
"Why doesn't this get faster when I add threads?" is the Python concurrency question that almost every developer interview reaches. The answer is the global interpreter lock, the GIL. The follow-up questions check whether you know what it does, and more importantly, what it does not protect.
What the GIL is
In the standard CPython build, a thread must hold the GIL to run Python bytecode, and only one thread holds it at a time. The running thread is asked to give it up every switch interval, 5 milliseconds by default, and it gives it up whenever it blocks on I/O or sleeps. C extensions can release it while they work on their own data, which numpy does in many array operations.
The GIL exists to protect the interpreter's own state, above all the reference counts from the previous lesson, without a separate lock on every object.
The rest of this lesson is for subscribers
Unlock every lesson in Programming for Quantitative Developers, and every other premium course.
Subscribe to continueTest your knowledge
Keep reading Programming for Quantitative Developers
33 lessons in this course, and every other premium course, on one subscription.
- Every lesson in every course, with the worked examples and interactive simulators
- Graded questions on every lesson, with explanations for the wrong answers as well as the right one
- The trainers, timed assessments and brainteaser library that go with them