GH-132657: Add lock-free set contains implementation

[nascheme]

This roughly follows what was done for dictobject to make a lock-free lookup operation. The set contains operation scales much better when used from multiple-threads. The frozenset contains performance seems unchanged (as already lock-free).

Summary of changes:

• refactor set_lookkey() into set_do_lookup() which now takes a function pointer that does the entry comparison. This is similar to dictobject and do_lookup(). In an optimized build, the comparison function is inlined and there should be no performance cost to this.
• change set_do_lookup to return a status separately from the entry value.
• add set_compare_frozenset() and use if the object is a frozenset. For the free-threaded build, this avoids some overhead (locking, atomic operations, incref/decref on key)
• use FT_ATOMIC_* macros as needed for atomic loads and stores
• use a deferred free on the set table array, if shared (only on free-threaded build, normal build always does an immediate free)
• for free-threaded build, use explicit for loop to zero the table, rather than memcpy().
• when mutating the set, assign so->table to NULL while the change is a happening. Assign the real table array after the change is done.

Free-threading scaling benchmark results from the attached scripts (result for 8 cores in parallel). This is a modified version of the ftscalingbenchmark.py script.

	base	this PR
dict_contains	9.1x faster	9.4x faster
tuple_contains	8.0x faster	7.6x faster
list_contains	7.9x faster	7.8x faster
frozenset_contains	7.8x faster	7.8x faster
frozenset_contains_dunder	7.6x faster	7.7x faster
set_contains	2.6x slower	7.7x faster
set_contains_dunder	2.8x slower	6.1x faster
shallow_copy	1.8x faster	1.8x faster
deepcopy	4.2x faster	4.5x faster

ftscaling_set.py.txt

• Issue: copy.copy and copy.deepcopy scale poorly with free-threading #132657

[bedevere-bot]

🤖 New build scheduled with the buildbot fleet by @nascheme for commit 70a1c1f 🤖

Results will be shown at:

https://buildbot.python.org/all/#/grid?branch=refs%2Fpull%2F132290%2Fmerge

If you want to schedule another build, you need to add the 🔨 test-with-buildbots label again.

[nascheme]

Hello @eendebakpt, since you have recently worked on the setobject.c source, perhaps you are able to take another look at this. I think the free-threaded scaling improvement is significant. I've merge with the main branch and updated the benchmark results.

[eendebakpt]

Why is the make_set here in a thread? It just assigns the same frozenset to s each time.

Maybe change make_set so that it creates a different frozenset each time?

[nascheme]

I don't understand this comment. The make_set() binds s to a new frozenset object (at least I intend it to).

[eendebakpt]

The s is indeed updated with a new frozenset, but it is a frozenset with the same elements each time. I was thinking about something like

def make_set():
            nonlocal s
            barrier.wait()
            num_elements = NUM_ITEMS
            while not done:
               num_elements = (num_elements  + 17 %) NUM_ITEMS
                s = frozenset(range(num_elements))

But what are we testing here. There is no concurrent mutation of the s, so this test is not specific to the free-threading build I think?

[nascheme]

Oh yes, I'm not sure what I was thinking when writing that test. It doesn't test what I intended. I re-wrote it so that a set() is used as the key and it mutated.

[eendebakpt]

Note to self: this is identical to the ensure_shared_on_read from dictobject.c. The SET_DICT_SHARED would correspond to SET_SET_SHARED, which is an odd name so here it is SET_MARK_SHARED.

[eendebakpt]

set_swap_bodies is only called in two locations in this file. For both cases the second argument b is a newly created temporary which is discarded afterwards. So we could replace part (all?) of these branches with asserts. Part of the other work (e.g. copying back to b) might not be needed for the same reason.

[nascheme]

That would simplify the code and be slightly faster (not sure how much it actually matters). I'll create a separate issue for that so we can benchmark it.

[eendebakpt]

Note: this path can be taken. set_lookkey_threadsafe is only called in set_contains_entry. The set_contains_entry is only called in _PySet_Contains. _PySet_Contains is called in set___contains___impl and in bytecodes.c _CONTAINS_OP_SET (the latter can have frozenset as input)

[eendebakpt]

What are we checking here and why? For the original code the PyObject_RichCompareBool could have changed the set, and these checks guard against this. However, in the free-threading setting a concurrent thread can change the set so after the table == FT_ATOMIC_LOAD_PTR_ACQUIRE(so->table) && startkey == FT_ATOMIC_LOAD_PTR_ACQUIRE(ep->key), but before the return cmp;. So any calling method cannot assume that when SET_LOOKKEY_FOUND is returned the key is still in the set.

Maybe adding the check help to preserve backwards compatibility in case of a mutating rich compare?

[nascheme]

I believe the "why" is to handle PyObject_RichCompareBool() mutating the set, via the restart. I think we want to preserve that, even for the free-threaded build, since some code that running single-threaded might assume set lookups handle mutation that way.