iSharkFly-Open
/
python-peps
mirror of https://github.com/python/peps.git
1
0
Fork 0
Code Issues Packages Projects Releases Wiki Activity

PEP 703: Minor edits (#3143)

This commit is contained in:
Sam Gross 2023-05-11 14:11:40 -04:00 committed by GitHub
parent 90640f47b7
commit cf1649c9d2
No known key found for this signature in database
GPG Key ID: 4AEE18F83AFDEB23
1 changed files with 15 additions and 9 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

24
pep-0703.rst
View File

@ -389,9 +389,9 @@ object's header: the "local" reference count, the "shared" reference
count, and the identifier of the owning thread. The BRC paper packs
these three things into a single 64-bit field. This PEP proposes using
three separate fields in each object's header to avoid potential issues
due to reference count overflow. Additionally, the implementation
proposed PEP supports a faster deallocation path that avoids an atomic
operation in the common case.
due to reference count overflow. Additionally, the PEP supports a
faster deallocation path that avoids an atomic operation in the common
case.
The proposed ``PyObject`` struct (also called ``struct _object``) is
below:
@ -941,7 +941,7 @@ from the memory allocator:
* ``list.contains``
Borrowed References
-------------------
'''''''''''''''''''
Per-object locking provides many of the important protections that the
GIL provides, but there are a few cases where it's not sufficient.
@ -975,7 +975,7 @@ dictionaries are effectively private (not accessible by other
threads).
Python Critical Sections
------------------------
''''''''''''''''''''''''
Straightforward per-object locking could introduce deadlocks that were
not present when running with the GIL. Threads may hold locks for
@ -1049,7 +1049,7 @@ two calls to ``Py_BEGIN_CRITICAL_SECTION`` because the inner critical
section may release the locks from the outer critical section.
Optimistically Avoiding Locking
-------------------------------
'''''''''''''''''''''''''''''''
A few operations on ``dict`` and ``list`` optimistically avoid
acquiring the per-object locks. They have a fast path operation that
@ -1163,7 +1163,7 @@ memory occupied by the Python object previously held a different
Mimalloc Changes for Optimistic ``list`` and ``dict`` Access
------------------------------------------------------------
''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''
The implementation requires additional constraints to the memory
allocator, including some changes to the mimalloc code. Some
@ -1198,7 +1198,7 @@ managed dictionaries.
Mimalloc Page Reuse
--------------------
'''''''''''''''''''
It is beneficial to keep the restrictions on mimalloc page reuse to a
short period of time to avoid increasing overall memory usage.
@ -1245,7 +1245,7 @@ empty blocks in the freed page, so the page can be used for any other
purpose or even returned to the operating system.
Optimistic ``dict`` and ``list`` Access Summary
-----------------------------------------------
'''''''''''''''''''''''''''''''''''''''''''''''
This PEP proposes a technique for thread-safe list and dictionary
accesses that typically avoids acquiring locks. This reduces
@ -1512,6 +1512,12 @@ Note that this PEP would not affect the performance of the default
.. _PR 19474: https://github.com/python/cpython/pull/19474
Build Bots
==========
The stable build bots will also include ``--disable-gil`` builds.
How to Teach This
=================