gh-112075: Make PyDictKeysObject thread-safe

[DinoV]

Adds locking for shared keys

• Issue: Make dict objects thread-safe in --disable-gil builds #112075

[corona10]

How about adding a macro for the free-threading version and the default version?

[corona10]

I did similar approach at listobject: 393cbef

See: _Py_SET_ITEMREF

[erlend-aasland]

@corona10 is there a significant difference in performance between the two builds? I'm not sure if it is worth it to add these preprocessor guards everywhere if there is no measurable effect :) Is there a different motivation than performance?

[colesbury]

Regardless of whether we do the macro approach everywhere, I think it's a good idea in this specific case (specifically for performance).

[colesbury]

This mostly looks good to me.

I don't think we want to be locking around shared_keys_usable_size(). It's both not sufficient for thread-safety at most of the call sites and not what we want to be doing for performance reasons.

[colesbury]

We can use a weaker ordering here that will be faster, especially on x86 where "release" doesn't require any memory barrier:

 _Py_atomic_store_ssize_relaxed(&keys->dk_nentries, keys->dk_nentries + 1);
_Py_atomic_store_ssize_release(&keys->dk_usable, keys->dk_usable - 1);

(I don't think we have _Py_atomic_store_ssize_release yet, though)

I find the memory orderings hard to reason correctly about, so I like to model them with CDSChecker. Here's the model I used for this:
https://github.com/colesbury/c11-model-checker/blob/cpython-models/test/gh-112075.c

[colesbury]

One minor formatting comment, but otherwise LGTM

[colesbury]

Suggested change

	}else {
	}
	else {