The global interpreter lock (GIL) allows only one Python thread to run at a time. Threads can execute concurrently as the runtime switches among them, but they do not execute Python code in parallel within one process. This simplifies runtime thread and memory management, while limiting multithreaded CPU-bound performance. section 16.1 section 16.6
The GIL belongs to a broader multithreading design problem:
- Threads share application data, code, files, and other resources, so shared resources still require synchronization. section 16.1
- Use threading for applications that inherently require multiple threads, especially when one thread waits for I/O and another can run. section 16.1
- Use multiprocessing when parallel execution is required; separate Python runtime systems sidestep the GIL. section 16.5
The shared frying pan
Several cooks may work concurrently, but only one can use a shared frying pan at a time. Similarly, threads may contend for shared resources and must protect critical regions with mutexes such as Python's Lock object. section 16.1 section 16.6
Figure 16.1 A multithreaded application with three threads. The threads share the application’s internal resources of code and data in memory and external resources such as printers and files. The runtime system gives each thread its own runtime stack and the appearance of having its own set of machine registers.
Use the diagram to distinguish each thread's private runtime stack from the code, memory, files, and other resources shared by the application. section 16.1
