gh-154756: Fix data race in list.sort()

[weixlu]

This PR try to fix #154756

The fix is straightforward: publish each slot write with FT_ATOMIC_STORE_PTR_RELEASE, just like the other list mutators already do. For example, ins1() (used by list.insert) also uses FT_ATOMIC_STORE_PTR_RELEASE(items[i+1], items[i])

Testing

• The reproducer now runs clean.
• PASS ./python -m test test_sort test_list

Notes for reviewer:

• On the default build (GIL-enabled), FT_ATOMIC_STORE_PTR_RELEASE expands to a plain store, so there is no change there.
• This PR only adds a atomic store, so basic functional behavior is unchanged.

• Issue: Data race in list.sort() on no-gil build #154756

• Issue: Free-threading data races in CPython: 15 findings (9 new + 6 residual of existing FT work) #153852

[brijkapadia]

1. Could you create a new issue instead of referencing the parent?
2. Are you sure using a lot of release atomics is the best approach?

[weixlu]

1. Could you create a new issue instead of referencing the parent?
2. Are you sure using a lot of release atomics is the best approach?

@brijkapadia Thanks for your review. Sure, I’ve created a separate issue.

You’re right that this PR introduces quite a few release atomic stores. However, I think most of them are necessary to preserve the required atomicity.

• listobject.c already contains 19 release atomic stores used by methods such as list.clear() and list.extend(), and I believe list.sort() requires similar changes.
• That said, 6 atomic stores can be removed. They are in the original ordinary insertion sort implementation, which has been superseded by binary insertion sort and is currently guarded by #if 0. Since this code no longer appears to be used, there is probably no need to update it. I initially added the atomic stores there as well simply to keep the implementations consistent.

[picnixz]

What is the performance impact for lists of various size?