Type slots are not thread-safe in free-threaded builds

[mpage]

Bug report

Bug description:

Modification of type slots is protected by the global type lock, however, type slots are read non-atomically without holding the type lock. For example, in PyObject_SetItem:

cpython/Objects/abstract.c

Lines 231 to 235 in 5bb059f

	if (m && m->mp_ass_subscript) {
	int res = m->mp_ass_subscript(o, key, value);
	assert(_Py_CheckSlotResult(o, "__setitem__", res >= 0));
	return res;
	}

It's not clear how we want to address this. From @colesbury in #127169 (comment):

I'd lean towards doing a stop-the-world pause when modifying the slot so that we don't need 
to change every read. I expect that to be a bit tricky since class definitions look like they're mutating 
the class.

CPython versions tested on:

3.13, 3.14, CPython main branch

Operating systems tested on:

Linux

Linked PRs

• gh-127266: avoid data races when updating type slots #131174
• gh-127266: avoid data races when updating type slots v2 #133177

[colesbury]

For future reference, you can reproduce this race by running the following test with TSAN enabled:

./python -m test test_opcache -m test_load_attr_method_lazy_dict