-
-
Notifications
You must be signed in to change notification settings - Fork 31k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Make set
thread-safe in --disable-gil
builds
#112069
Comments
Hi again! This one looks more challenging than the hashlib one but I'd like to try anyway :) |
Thanks @tomasr8! |
hi @tomasr8, just curious if you're still planning on working on this? |
Hi! 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 |
This makes nearly all the operations on set thread-safe in the free-threaded build, with the exception of `_PySet_NextEntry` and `setiter_iternext`. Co-authored-by: Sam Gross <[email protected]> Co-authored-by: Erlend E. Aasland <[email protected]>
…ython#113800)" The "AMD64 Debian root 3.x" is failing with strange errors. This reverts commit c951e25.
…113800) This makes nearly all the operations on set thread-safe in the free-threaded build, with the exception of `_PySet_NextEntry` and `setiter_iternext`. Co-authored-by: Sam Gross <[email protected]> Co-authored-by: Erlend E. Aasland <[email protected]>
@colesbury I am going to work on |
…113800) This makes nearly all the operations on set thread-safe in the free-threaded build, with the exception of `_PySet_NextEntry` and `setiter_iternext`. Co-authored-by: Sam Gross <[email protected]> Co-authored-by: Erlend E. Aasland <[email protected]>
@colesbury Now we can close the issue right? Or more thing is left? |
Yeah, I think so |
Feature or enhancement
The
set
object is not currently thread-safe in--disable-gil
builds. 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:
dict
andlist
, 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_len
can 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.12
fork: 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_SECTION
takes 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_init
if possible_PySet_NextEntry
setiter_iternext
Linked PRs
The text was updated successfully, but these errors were encountered: