gh-115999: Add free-threaded specialization for STORE_SUBSCR
#127169
Conversation
The specialization only depends on the type, so no special thread-safety considerations there. STORE_SUBSCR_LIST_INT needs to lock the list before modifying it. `_PyDict_SetItem_Take2` already internally locks the dictionary using a critical section.
| // avoid any potentially escaping calls (like PyStackRef_CLOSE) while the | ||
| // object is locked. | ||
| #ifdef Py_GIL_DISABLED | ||
| # define LOCK_OBJECT(op) PyMutex_LockFast(&(_PyObject_CAST(op))->ob_mutex) |
There was a problem hiding this comment.
@mpage, I think this locking pattern will be slightly faster than using critical sections inline in bytecodes.c. The downside is that we will deopt if there's any lock contention, but I think that's an okay tradeoff.
If we decide to go with this pattern, we can update UNPACK_SEQUENCE_LIST to use it.
|
@corona10 - I put my name down next to |
|
( |
| // avoid any potentially escaping calls (like PyStackRef_CLOSE) while the | ||
| // object is locked. | ||
| #ifdef Py_GIL_DISABLED | ||
| # define LOCK_OBJECT(op) PyMutex_LockFast(&(_PyObject_CAST(op))->ob_mutex) |
| if (as_mapping && (as_mapping->mp_ass_subscript | ||
| == PyDict_Type.tp_as_mapping->mp_ass_subscript)) { |
There was a problem hiding this comment.
I think it's possible for a data race to occur between the load in as_mapping->mp_ass_subscript and an assignment to the same field in another thread (potentially as a result of Python code assigning to the type's __setitem__ attr). I'm not totally sure what we want to do here, but a couple of thoughts:
- We could use an atomic load in
as_mapping->mp_ass_subscriptand change the code intypeobject.cthat updates the slots to use atomic stores. - Or, since this only happens in stats builds and is benign (to the extent that a data race is benign), we could just ignore it.
Race condition with the wrong lock :) Fine, thank you for the work, I've updated the list of issues. |
There was a problem hiding this comment.
Please add test codes at test_opcache.py
cpython/Lib/test/test_opcache.py
Line 1227 in d24a22e
The specialization only depends on the type, so no special thread-safety considerations there.
STORE_SUBSCR_LIST_INT needs to lock the list before modifying it.
_PyDict_SetItem_Take2already internally locks the dictionary using a critical section.--disable-gilbuilds #115999