Repository navigation
Make set thread-safe in --disable-gil builds #112069
Description
Activity
Hi again! This one looks more challenging than the hashlib one but I'd like to try anyway :)
Reacted by Sam GrossReacted by Erlend E. AaslandHi! Yes, I took a break for Christmas but I have it almost working, just need to fix some tests. I could open a draft PR this weekend
Reacted by Dino ViehlandReacted by Erlend E. Aasland- added a commit that references this issue
on Apr 16, 2024 @colesbury I am going to work on
_PySet_NextEntrythis week, considering the caller-side usage.- added 7 commits that reference this issue
on Apr 17, 2024 @colesbury Now we can close the issue right? Or more thing is left?
Yeah, I think so
Reacted by Donghee Na
Feature or enhancement
The
setobject is not currently thread-safe in--disable-gilbuilds. We should make it thread-safe by using the "critical section" API. to acquire the per-object locks around operations. There should be no effective change in the default build (i.e., with GIL) because critical sections are no-ops in the default build.Notes:
dictandlist, I don't think it's worth the complexity to try to "optimistically avoid locking" around any set operation (exceptset_len). We could consider doing this in the future if there is a performance justification, but not for 3.13.set_lencan avoid locking and instead use relaxed atomics for reading the "used" field. Note that writes to "used" should then also use relaxed atomics.set_merge). Some of these will need refactorings so that the critical sections macros can be added in the correct places.For context, here is the change from the
nogil-3.12fork: colesbury/nogil-3.12@4ca2924f0d. Note that the critical section API is slightly changed in 3.13 fromnogil-3.12; In 3.13Py_BEGIN_CRITICAL_SECTIONtakes a PyObject instead of a PyMutex.TODO:
set_init(see gh-112069: Make sets thread-safe with the GIL disabled #113800 (comment)). We also want to avoid locking inset_initif possible_PySet_NextEntrysetiter_iternextLinked PRs