Repository navigation
Add more test coverage for concurrent set operations #158093
Description
Activity
Can you, in a wider search, determine if there are more tests to add for set.* in general? we can then extend the issue instead of having it for a single method.
Note that such tests may also be elsewhere so be careful.
Can you, in a wider search, determine if there are more tests to add for set.* in general? we can then extend the issue instead of having it for a single method.
What I can quickly come up with now is adding some cases for "add()+remove()" or "copy() during mutation" across multiple threads.
This is my first PR and my first time working with free-threaded Python, so I want to start with a single method to make sure I am on the right track.
We prefer first knowing the scope of the issue before opening PRs. It is important to understand what is lacking first. I am surprised that we have no such tests and some of that could be found in test_builtins or in other test files.
@picnixz
As I understand, there are only two files for testing a set object:Lib/test/test_set.pytests the correctness of the set implementation on a single thread.Lib/test/test_free_threading/test_set.pytests whether the set can be run using free-threaded Python.
So, I don't think there are any other files that contain tests for the set on free-threaded Python.
My thought is that more coverage that checks results when a set is modified from multiple threads in a free-threaded build should be added. The current tests mainly check that concurrent operations complete without a crash or deadlock. There is only one test checking that each
repr()result is either the complete initial set or the empty set. I propose adding tests where several threads mutate the same set and the final contents can be checked, such as follows.- calling
pop()on several threads on the same set, and checking if the final result is correct (such as the set being empty and no thread getting a duplicate element) - calling
add()on several threads using disjoint inputs, and checking if the final result is their union - calling
remove()/discard()on several threads on the same set, and checking if the final result is correct - calling operations such as
update()on the same two shared sets. For example, thread 1 callsset1.update(set2), while thread 2 callsset2.update(set1). The final result is that both sets are correct and no deadlock happens.
These are only some cases I can think of now. But what I think is that it would be better if there were more test cases to test a set object in free-threaded Python.
If those cases are not already tested, it would be great for you to update your PR with them. Let's have a single PR that brings more test coverage for
setunder free-threading rather than having multipe small PRs. Can you do it please?Yes, I can!
Reacted by Bénédikt Tran- changed the title
[-]Add test coverage for concurrent set.pop() calls[/-][+]Add more test coverage for concurrent set operations[/+]on Sep 30, 2026 My PR has been updated with the additional concurrent set tests.
This test aims for a free-threaded Python.
Testcases in
Lib/test/test_free_threading/test_set.pydo not cover a case where several threads pop from the same set. So, I want to add a test where.popis called by several threads on the same set.My test checks whether the original items are returned exactly once (no duplicates) and the popped set ends up empty.
This is my first time contributing to CPython, so I welcome any advice! I will create a PR soon.
Linked PRs