Python’s Global Interpreter Lock (GIL) is the mechanism which ensures only one (C)Python instruction is being executed at any one time. While an apparent major limitation, its practical effect are often small if following steps are followed.

What do I need to do about GIL?

-1. Do not panic! Python is routinely used in efficient, scalable programs.

  1. Whenever possible use existing libraries (numpy, tensorflow, dask, etc) which have thought about all this for you.

  2. If you are writing a Python extension, and a function in it may spend a long (continuous) period not executing Python instructions, then release the GIL. A few milliseconds probably counts as “long”, 15 milliseconds is definitely “long” (see bellow).

    If you do release the GIL, you must re-acquire it before calls into the Python C API.

  3. If you need to improve performance of a Python program that is executing a lot of Python instructions (not e.g. doing numpy computations, or waiting for I/O, etc) then use multiprocessing

What do I need to know about the GIL

  1. Holding the GIL is not a guarantee that thread-unsafe C libraries will be safe to use (for example a thread that does not need GIL can continue to access these libraries). See also below.

  2. A thread holding GIL may be interrupted any time a Python interpreter instruction is executed in that thread, in which case execution is suspended and it temporarily looses the GIL.

    Hence GIL is never a substitute for any type of locking at the Python level.

How to find out all about GIL yourself

Sometimes, reading descriptions does not help, you need to experiment to convince yourself what is going on. Fortunately it is easy to experiment with the GIL using Cython, which allows creation of compiled functions that can optionally release the GIL.

Here are the ingredients that will allow us the experiment with GIL.

Releasing the GIL

The following Cython function demonstrates a section of code for which the GIL has been released. Note that the C-language printf is used so that there is no need to call back into Python.

from libc.stdio cimport printf

def fn1():
    with nogil:
        printf("No GIL!\n")        

Sleeping to simulate work in the thread

We use the c-library function usleep to block the thread to simulate what in a real-world situation would have been some useful computation:

from posix.unistd cimport usleep

def fn2():

Calling back into python

If a section of Cython code has not released the GIL it can call back into Python. We will do this simply by calling print instead of printf. Note that since print will execute Python instructions, control may switch to another thread!

def workCA():
    printf("A - start\n")
    print("A - mid\n")
    printf("A - end\n")

A threaded Python program

In Python we can easily start multiple threads using the threading library as follows:

import threading
import time

def SA():
    for i in range(5):

def SB():
    for i in range(5):



Easy use of Cython during development

I use the following header so that Cython can be imported straight into a module without a compilation step. This makes it easy to iteratively develop Cython programs

import pyximport; pyximport.install()

Putting it together

Here is the simplest examples, which shows that if you release the GIL multiple threads will run in parallel:

def workNA():
    with nogil:
        printf("A - start\n")        
        printf("A - mid\n")            
        printf("A - end\n")                

def workNB():
    with nogil:
        printf("B - start\n")        
        printf("B - mid \n")            
        printf("B - end \n")

Five iterations in each of two threads will complete in 10 seconds as opposed to 20 seconds if the GIL had not been released!

Some production examples to look at

  • Numpy: see e.g.

  • The built-in _sre module, which does not release the GIL (see e.g.