last yearAt the 2022 Python Language Summit, developer Sam Gross Brought itNew proposal: delete the global interpreter lock GIL to liberate multi-threading performance.However, due to the long history of GIL, many official/unofficial Python packages and modules are deeply integrated with GIL modules, and the complete removal of GIL functions may have an impact on the ecology.in 2023 January 9, Sam Gross has created another Python Proposal PEP 703: Make the Global Interpreter Lock optional for building Python.

CPython’s Global Interpreter Lock (“GIL”) prevents multiple threads from executing Python code at the same time, and the GIL is an obstacle to Python’s efficient use of multi-core CPUs.

Add a build configuration to CPython ( --without-gil) to allow it to run Python code without the global interpreter lock, and make the necessary changes to make the interpreter thread-safe.

The content of this PEP proposal can be described as a paper level.The proposal first expounded the GIL’s performance hindrance to Python concurrency, and then analyzed the abstraction in detail. GIL What changes need to be made to Python internals:

Removing the Global Interpreter Lock required extensive changes to CPython internals, but relatively few changes to the public Python and C APIs.

The implemented changes fall into roughly the following four categories:

Reference counting, memory management, container thread safety, locks and atomic API

Since the content of this proposal is too much, interested friends please read it carefully in the PEP 703 details page and the discussion thread of the proposal by Cpython core developers.

At present, this PEP has a reference implementation, and its prototype originated from the nogil project developed to remove the GIL. The prototypeBrings a noticeable (~10%) performance boost to single-threaded code.

If the proposal passes, it meansCPython does not remove or turn off the GIL by default, nor does it allow users to selectively enable/remove the GIL.because--without-gilis a compile-time flag that can be set when building the Python interpreter from source. But deprecating that configuration would result in deeply invasive changes to how the interpreter is built and run, which is also detailed in the PEP.

On the user side, this change means that if users use any package with compiled extensions, they will need to obtain or build a version compiled specifically for the (different) ABI of the Python interpreter, which works without the GIL compile.

About the Python GIL

Since CPython’s memory management is not thread-safe, CPython’s GIL (Global Interpreter Lock – Global Interpreter Lock) was designed to prevent race conditions and ensure thread safety. The GIL is a mutex that allows only one thread to hold control of the Python interpreter, thereby protecting access to Python objects and preventing multiple threads from executing Python bytecode at the same time.

But in hindsight, the GIL is not ideal, because it prevents multi-threaded CPython programs from taking full advantage of the performance of multi-core processors.