delete misleading faq entry about atomic operations

[graingert]

BPO	45435
Nosy	@pitrou, @stevendaprano, @serhiy-storchaka, @jeff5, @graingert, @pablogsal, @bensimner
PRs	bpo-45435: delete misleading faq entry about atomic operations #28886

^{Note: these values reflect the state of the issue at the time it was migrated and might not reflect the current state.}

Show more details

GitHub fields:

assignee = None
closed_at = None
created_at = <Date 2021-10-11.20:25:32.309>
labels = ['3.11', 'type-bug', '3.9', '3.10', 'docs']
title = 'delete misleading faq entry about atomic operations'
updated_at = <Date 2021-10-12.23:09:38.937>
user = 'https://github.com/graingert'

bugs.python.org fields:

activity = <Date 2021-10-12.23:09:38.937>
actor = 'bjs'
assignee = 'docs@python'
closed = False
closed_date = None
closer = None
components = ['Documentation']
creation = <Date 2021-10-11.20:25:32.309>
creator = 'graingert'
dependencies = []
files = []
hgrepos = []
issue_num = 45435
keywords = ['patch']
message_count = 8.0
messages = ['403700', '403714', '403715', '403716', '403725', '403729', '403754', '403765']
nosy_count = 8.0
nosy_names = ['pitrou', 'steven.daprano', 'docs@python', 'serhiy.storchaka', 'jeff.allen', 'graingert', 'pablogsal', 'bjs']
pr_nums = ['28886']
priority = 'normal'
resolution = None
stage = 'patch review'
status = 'open'
superseder = None
type = 'behavior'
url = 'https://bugs.python.org/issue45435'
versions = ['Python 3.9', 'Python 3.10', 'Python 3.11']

[stevendaprano]

Why do you say that the FAQ is misleading?

If it is misleading, it should be replaced with a more correct answer, not just deleted.

[jeff5]

I'm interested in Thomas' reasons, but here are some of mine (as far as I understand things):

1. It is specific to one interpreter implemented in C, equipped with a GIL, and on certain assumptions about the byte code interpreter and the implementation of built-ins, that may not hold long-term.

2. In x = L[i], the index and assignment are distinct actions (in today's byte code), allowing L or i to change before x is assigned. This applies to multiple other of the examples.

3. A compiler (even a CPU) is free to re-order operations and cache values in unguessable ways, on the assumption of a single thread.

4. Code written on these principals is fragile. It only takes the replacement of a built-in with sub-class redefining __getitem__ (to support some worthy aim elsewhere in the code) to invalidate it.

5. sort() is not atomic if an element is of a type that overrides comparison in Python. (Nor is modifying a dictionary if __hash__ or __eq__ are redefined.)

If you want retain the question, with a better answer, the last sentence is good: "When in doubt, use a mutex!", accompanied by "Always be in doubt."

[graingert]

it's as part of this discussion in https://mail.python.org/archives/list/python-dev@python.org/thread/ABR2L6BENNA6UPSPKV474HCS4LWT26GY/#IAOCDDCJ653NBED3G2J2YBWD7HHPFHT6 and others in #python-dev

specifically

cpython/Objects/dictobject.c

Lines 2582 to 2586 in 2f92e2a

	if (n != other->ma_keys->dk_nentries) {
	PyErr_SetString(PyExc_RuntimeError,
	"dict mutated during update");
	return -1;
	}

regarding if any of the items are builtins or not: the faq entry lists (L, L1, L2 are lists, D, D1, D2 are dicts, x, y are objects, i, j are ints) so I read that to mean x and y are user defined objects with user defined comparison and equality methods

[pitrou]

I'm also surprised to learn that L.sort() and D1.update(D2) are supposed to be atomic. They certainly are not in the general case.

Remember, any Python code can release the GIL (because the GIL is released periodically in the interpreter loop). Any DECREF can also release the GIL (because it may trigger the execution of arbitrary destructors). This restricts a lot which operations can be safely considered atomic.