I just worked on 2 methods because list_length is the first method that requires _Py_atomic_load_ssize_relaxed which creates fragmented implementation. until now, just using Py_BEGIN_CRITICAL_SECTION API or @critical_section annotation was enough, but from now it's not.

So from now, I would like to check other core devs opinions about this.

I expect that @serhiy-storchaka can propose a better solution :)
Also, @ambv can have other ideas about this.
The reference implementation is based on colesbury/nogil-3.12@df4c51f82b

Once we decide about the fragmented implementations with atomic API, we can start to implement the rest of things in a unified and satisfied way.

This looks maintainable enough to me.

I can't quite check if it's “thread safe” -- AFAIK we don't really define what that is, yet.
One thing that's not clear to me is whether Py_SIZE itself should be atomic, or if all calls to it should be replaced by an atomic load (or in critical sections).

I think that either all reads and writes of ob_size should be atomic, or they all should be in critical sections.

@colesbury
What about making Py_SIZE() to be atomic instead of touching this from runtime implementation?
A side effect is that there will be some minor effect to something like a tuple, but not that huge IIUC.

If we are okay with this, I will submit a new PR.

@colesbury

Updated! The implementations become more clear and easy to maintain.
Now I understand our consensus about how to handle atomic operations in runtime.
I will submit PRs with similar approaches.

@serhiy-storchaka wrote:

I think that either all reads and writes of ob_size should be atomic, or they all should be in critical sections.

I think we should follow slightly different pattern in list:

• Writes to ob_size should be atomic AND in critical sections
• Reads from ob_size should be either atomic OR in critical sections

Exceptions: initialization, deallocation, and certain special functions can use plain accesses without critical sections (e.g., PyList_New(), list_dealloc, list_traverse).

The motivation behind this is that we will have some accesses outside of critical sections (see "Optimistic dict and list Access Summary" in PEP 703), so we can't use critical sections everywhere, but we will use them for most operations.

At the same time, I think we should prefer plain, non-atomic reads from within critical sections. We could conservatively use atomic reads and still be correct, but my experience is that adding atomic operations where they are not necessary tends to hide data races from thread sanitizer.

Note that writes to ob_size have to be at atomic even if they are within critical sections because there might be concurrent reads.

You at least need to make writing the list size atomic.

You at least need to make writing the list size atomic.

I agree, but I don't think we should do that in this PR. I think it's easier to write and review the PRs organized around functions than around fields (i.e., "fix list_repr" instead of "fix ob_size"). It keeps the changes smaller and close together.

The current changes look sufficient to me if we later address all the functions that write to ob_size.

The current changes look sufficient to me if we later address all the functions that write to ob_size.

Yeah, I will prepare another PR for this.

Thank you @serhiy-storchaka, @encukou and @colesbury about discussing how we handle atomic operation issue :)
It's now become clear :)