Repository navigation
gh-151377: Fix races updating type slots and subclasses in free-threa… - #151394
lpyu001 wants to merge 3 commits into
Conversation
Sorry, something went wrong.
add NEWS entry
|
Tested on Ubuntu 24.04，did not observe TSAN warnings. |
Sorry, something went wrong.
|
Using STW (stop-the-world) is a big hammer and could have significant performance issues. If at all possible, we should avoid it when creating types. I think a potential alternative solution is to do the slot update before we publish the new type. See this branch for a prototype implementation: https://github.com/nascheme/cpython/tree/gh-151377-type-data-race Note that re-org of the type init steps is tricky and we need to be careful this doesn't cause some kind of bug. I would prefer this approach if we can make it work. STW is likely too expensive to do on this code path. |
Sorry, something went wrong.
In free-threaded builds, a newly created heap type can become visible through its base type’s subclasses dictionary after PyType_Ready(). Updating its slot dispatchers after that point must not write slot pointers unsafely while other threads may observe or update the type hierarchy.
This change makes fixup_slot_dispatchers() hold TYPE_LOCK in free-threaded builds, queue the required slot updates, and apply them with the world stopped. It also protects removal from base tp_subclasses during type deallocation with TYPE_LOCK.
Additionally, the debug-only _Py_TYPE_REVEALED_FLAG is read and written from different threads by type-safety assertions, so its accesses are changed to atomic operations to avoid TSAN reports on the debug marker itself.