Understand the GIL and Write a C Extension That Releases It

The Global Interpreter Lock

CPython's GIL is a mutex that lets only one thread execute Python bytecode at a time per process. It simplifies object refcounting but limits CPU-bound parallelism across threads.

Why It Exists and How to Release It

The GIL protects CPython's internal structures during concurrent access. Reference count updates, object allocation, and many C API calls assume the GIL is held.

CPU-bound C extensions can release it around long native work:

cCopy
Loading…

When the GIL helps versus hurts:

• I/O bound: threads overlap waiting on disk or network while the GIL is released
• CPU bound in Python: threads time-slice on one core; little parallel speedup
• CPU bound in C with release: native work runs in parallel after Py_BEGIN_ALLOW_THREADS

I/O-bound threads still benefit because blocking syscalls release the GIL while waiting. CPU-bound Python threads on multiple cores, however, mostly take turns holding one lock.

For example, two threads each computing Fibonacci in pure Python rarely achieve 2x throughput; one thread runs bytecode while the other waits.

Design Notes

Extensions that call back into Python API while holding native locks can deadlock with the GIL. Release the GIL before long C work, re-acquire before touching PyObject* unless you know the object is immortal.

For This Exercise

This exercise asks you to explain GIL behavior and write a C extension skeleton that releases the lock during heavy work. You will document when threads help (I/O) versus when they do not (CPU-bound Python code).