[WIP] gh-123358: Update LOAD_DEREF to use stackref and atomic incref

[corona10]

• Issue: Concurrent reads from cell objects (LOAD_DEREF) do not scale well #123358

[corona10]

@Fidget-Spinner I am still working on :) I will ping you once I am ready!

[corona10]

@colesbury Let's extract the utility function with separated PRs.

[corona10]

@Fidget-Spinner
Ken, Would you like to take a look at overall approach for both stack effect and stackref side?

I am not sure that I do correctly so before checking why Windows free-threaded is failed, I would like to get rough review.
Thank you for understanding.

[Fidget-Spinner]

This is a little suspicious. Why do we need the atomics when there's the critical section?

[corona10]

Let me check,, yeah we may don't need this.

[corona10]

SUMMARY: ThreadSanitizer: data race /home/runner/work/cpython/cpython/./Include/internal/pycore_cell.h:23:18 in PyCell_SwapTakeRef

Maybe TSAN thought that they could be memory ordering issue.

@colesbury, Do you think that this would be false alarm?

[colesbury]

We need the second atomic write here (to cell->ob_ref), but not the first one. In other words, something like:

old_value = cell->ob_ref;
FT_ATOMIC_STORE_PTR_RELEASE(cell->ob_ref, value);

Although the write happens in the critical section, the read happens (with this PR) outside of the lock. This is the same pattern we use in dictionaries :

cpython/Objects/dictobject.c

Lines 278 to 279 in da5855e

	#define STORE_KEY(ep, key) FT_ATOMIC_STORE_PTR_RELEASE(ep->me_key, key)
	#define STORE_VALUE(ep, value) FT_ATOMIC_STORE_PTR_RELEASE(ep->me_value, value)

[corona10]

I suspect that there would be a deadlock issue at the Windows build. I am under investigation.
But before that, I would like to know there is any wrong code about stack effect and stack ref.

[Fidget-Spinner]

But before that, I would like to know there is any wrong code about stack effect and stack ref.

Don't think so.

[corona10]

@colesbury found that there is a possible issue from

cpython/Lib/test/lock_tests.py

Lines 117 to 121 in 5e7eba0

	def wait_phase(self, phase, expected):
	for _ in support.sleeping_retry(support.SHORT_TIMEOUT):
	if len(phase) >= expected:
	break
	self.assertEqual(len(phase), expected)

which cause this TSAN error. We should fix it with a separate PR.

[markshannon]

I don't think we need to use the extra indirection of passing a pointer to a stack ref

[markshannon]

Suggested change

	_PyCell_GetStackRef(PyCellObject *cell, _PyStackRef *value_addr)
	_PyStackRef _PyCell_GetStackRef(PyCellObject *cell)

I think that this can return the new _PyStackRef directly instead of via pointer, since there can be no garbage collection in this function.

[markshannon]

This can be left as scalar, for the reason given above.

[DinoV]

I wonder if in _Py_TryIncRefShared we could just do an atomic add to the ob_ref_shared if the object is already marked as weakref'd? E.g:

Py_ssize_t shared = _Py_atomic_load_ssize_relaxed(&op->ob_ref_shared);
for (;;) {
    if ((shared & _Py_REF_SHARED_FLAG_MASK) == _Py_REF_MAYBE_WEAKREF) {
        _Py_atomic_add_ssize(&op->ob_ref_shared, (1 << _Py_REF_SHARED_SHIFT));
       return 1;
    }
}

That might avoid the threads spinning on updating the value when the value is in heavy contention and instead all of the atomic operations should just slowly proceed.