-
-
Notifications
You must be signed in to change notification settings - Fork 30.5k
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
gh-112075: Add critical sections for most dict APIs #114508
Conversation
937afe2
to
1b5b406
Compare
1b5b406
to
8695859
Compare
65dede8
to
4118b1d
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This generally looks good. I included a number of formatting suggestions. Take them or leave them as you wish.
dictiter_iternextkey(PyObject *self) | ||
{ | ||
dictiterobject *di = (dictiterobject *)self; | ||
PyDictObject *d = di->di_dict; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We'll need a bit more work to make concurrent next(it)
thread-safe on the same iterator. That's not quite as urgent, but let's not lose track of it.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I actually have that ready to go I believe in what will become the PR for lcok-free thread-safe iteration, just need to get other things landed first :)
c326efa
to
d25c9a0
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM
#ifdef Py_DEBUG | ||
|
||
#define _Py_CRITICAL_SECTION_ASSERT_OBJECT_LOCKED(op) \ | ||
if (Py_REFCNT(op) != 1) { \ |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Maybe adjust the whitespace before \
d25c9a0
to
ab5d224
Compare
|
|
) Starts adding thread safety to dict objects. Use @critical_section for APIs which are exposed via argument clinic and don't directly correlate with a public C API which needs to acquire the lock Use a _lock_held suffix for keeping changes to complicated functions simple and just wrapping them with a critical section Acquire and release the lock in an existing function where it won't be overly disruptive to the existing logic
Starts adding thread safety to dict objects.
Adds critical sections around most APIs. Doesn't add any thread safety to the get-path as that'll be covered later.
There's generally 3 variations in here:
@critical_section
for APIs which are exposed via argument clinic and don't directly correlate with a public C API which needs to acquire the lock_lock_held
suffix for keeping changes to complicated functions simple and just wrapping them with a critical sectionMost things are made thread safe, I think the one glaring exception is that fetches of a single item are not thread safe. I'm hoping we can get the QSBR support in sooner rather than later and get that working. This does make iteration thread safe but it requires a lock which is not the long term plan so eventually that should become lock-free.
This specifically doesn't address the other issues for dict thread safety called out in the issue, it's just addressing the critical sections.
dict
objects thread-safe in--disable-gil
builds #112075