From 31b748c7dc36d39457f5388bb7c7054d6d99d0de Mon Sep 17 00:00:00 2001 From: Thomas Grainger Date: Mon, 11 Oct 2021 21:26:32 +0100 Subject: [PATCH 1/2] bpo-45435: delete misleading faq entry about atomic operations --- Doc/faq/library.rst | 43 ------------------------------------------- 1 file changed, 43 deletions(-) diff --git a/Doc/faq/library.rst b/Doc/faq/library.rst index e92973a2e8fa9a..330301b42b95a8 100644 --- a/Doc/faq/library.rst +++ b/Doc/faq/library.rst @@ -362,49 +362,6 @@ Consult the module's documentation for more details; the :class:`~queue.Queue` class provides a featureful interface. -What kinds of global value mutation are thread-safe? ----------------------------------------------------- - -A :term:`global interpreter lock` (GIL) is used internally to ensure that only one -thread runs in the Python VM at a time. In general, Python offers to switch -among threads only between bytecode instructions; how frequently it switches can -be set via :func:`sys.setswitchinterval`. Each bytecode instruction and -therefore all the C implementation code reached from each instruction is -therefore atomic from the point of view of a Python program. - -In theory, this means an exact accounting requires an exact understanding of the -PVM bytecode implementation. In practice, it means that operations on shared -variables of built-in data types (ints, lists, dicts, etc) that "look atomic" -really are. - -For example, the following operations are all atomic (L, L1, L2 are lists, D, -D1, D2 are dicts, x, y are objects, i, j are ints):: - - L.append(x) - L1.extend(L2) - x = L[i] - x = L.pop() - L1[i:j] = L2 - L.sort() - x = y - x.field = y - D[x] = y - D1.update(D2) - D.keys() - -These aren't:: - - i = i+1 - L.append(L[-1]) - L[i] = L[j] - D[x] = D[x] + 1 - -Operations that replace other objects may invoke those other objects' -:meth:`__del__` method when their reference count reaches zero, and that can -affect things. This is especially true for the mass updates to dictionaries and -lists. When in doubt, use a mutex! - - Can't we get rid of the Global Interpreter Lock? ------------------------------------------------ From 772171d80768e03c91bf1193519fcf48ad1539cb Mon Sep 17 00:00:00 2001 From: "blurb-it[bot]" <43283697+blurb-it[bot]@users.noreply.github.com> Date: Mon, 11 Oct 2021 20:30:35 +0000 Subject: [PATCH 2/2] =?UTF-8?q?=F0=9F=93=9C=F0=9F=A4=96=20Added=20by=20blu?= =?UTF-8?q?rb=5Fit.?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit --- .../next/Documentation/2021-10-11-20-30-33.bpo-45435.KpqCoj.rst | 1 + 1 file changed, 1 insertion(+) create mode 100644 Misc/NEWS.d/next/Documentation/2021-10-11-20-30-33.bpo-45435.KpqCoj.rst diff --git a/Misc/NEWS.d/next/Documentation/2021-10-11-20-30-33.bpo-45435.KpqCoj.rst b/Misc/NEWS.d/next/Documentation/2021-10-11-20-30-33.bpo-45435.KpqCoj.rst new file mode 100644 index 00000000000000..153282a867697e --- /dev/null +++ b/Misc/NEWS.d/next/Documentation/2021-10-11-20-30-33.bpo-45435.KpqCoj.rst @@ -0,0 +1 @@ +delete misleading faq entry about atomic operations \ No newline at end of file