Differences between revisions 7 and 8
Revision 7 as of 2007-10-16 17:42:28
Size: 2899
Comment:
Revision 8 as of 2007-10-16 17:58:24
Size: 2899
Editor: c-71-228-235-214
Comment: clean up language a bit
Deletions are marked like this. Additions are marked like this.
Line 6: Line 6:
The GIL is controversial because it prevents multi-threaded CPython programs from taking full advantage of multiprocessor systems in certain situations. Note that potentially blocking or long-running operations, such as I/O, image processing, and NumPy number crunching, happen ''outside'' the GIL. Therefore it is only in multi-threaded programs that spend a lot of time inside the GIL, interpreting CPython bytecode, that the GIL becomes a bottleneck. The GIL is controversial because it prevents multithreaded CPython programs from taking full advantage of multiprocessor systems in certain situations. Note that potentially blocking or long-running operations, such as I/O, image processing, and NumPy number crunching, happen ''outside'' the GIL. Therefore it is only in multithreaded programs that spend a lot of time inside the GIL, interpreting CPython bytecode, that the GIL becomes a bottleneck.
Line 28: Line 28:
 * '''Source compatibility.''' The proposal must be source-compatible with the macros used by all existing CPython extensions (`Py_INCREF` and friends). See [http://docs.python.org/api/countingRefs.html Python/C API Reference Manual: Reference Counting].  * '''Source compatibility.''' The proposal should be source-compatible with the macros used by all existing CPython extensions (`Py_INCREF` and friends). See [http://docs.python.org/api/countingRefs.html Python/C API Reference Manual: Reference Counting].

In CPython, the global interpreter lock, or GIL, is a mutex that prevents multiple native threads from executing Python bytecodes at once. This lock is necessary mainly because CPython's memory management is not thread-safe. (However, since the GIL exists, other features have grown to depend on the guarantees that it enforces.)

CPython extensions must be GIL-aware in order to avoid defeating threads. For an explanation, see [http://docs.python.org/api/threads.html Global interpreter lock].

The GIL is controversial because it prevents multithreaded CPython programs from taking full advantage of multiprocessor systems in certain situations. Note that potentially blocking or long-running operations, such as I/O, image processing, and NumPy number crunching, happen outside the GIL. Therefore it is only in multithreaded programs that spend a lot of time inside the GIL, interpreting CPython bytecode, that the GIL becomes a bottleneck.

Non-CPython implementations

Jython and IronPython have no GIL and can fully exploit multiprocessor systems.

[Mention place of GIL in StacklessPython.]

Eliminating the GIL

Getting rid of the GIL is an occasional topic on the python-dev mailing list. No one has managed it yet. The following properties are all highly desirable for any potential GIL replacement; some are hard requirements.

  • Simplicity. The proposal must be implementable and maintainable in the long run.

  • Concurrency. The point of eliminating the GIL would be to improve the performance of multithreaded programs. So any proposal must show that it actually does so in practice.

  • Speed. The ["BDFL"] has said he will reject any proposal in this direction that slows down single-threaded programs. (citation needed)

  • Features. The proposal must support existing CPython features including __del__ and weak references.

  • Source compatibility. The proposal should be source-compatible with the macros used by all existing CPython extensions (Py_INCREF and friends). See [http://docs.python.org/api/countingRefs.html Python/C API Reference Manual: Reference Counting].

  • Prompt destruction (nice to have?). The existing reference-counting scheme destroys objects as soon as they become unreachable, except for objects in reference cycles. Those are collected later by Python's cycle collector. Some CPython programs depend on this, e.g. to close files promptly, so it would be nice to keep this feature.

  • Ordered destruction (nice to have?). Barring cycles, Python currently always destroys an unreachable object X before destroying any other objects referenced by X. This means all the object's attributes are still there when __del__ runs. (Many garbage collection schemes don't guarantee this.)

GlobalInterpreterLock (last edited 2020-12-22 21:57:53 by eriky)

Unable to edit the page? See the FrontPage for instructions.