Description
Bug report
Bug description:
First of all, I'm not a threading expert and my understanding of the memory-ordering model may be wrong. So, if I'm wrong I will be happy to fix my knowledge lacoons.
I saw some inconsistency (from my sight) of loading and writing of managed dict pointer.
Non-atomic loads:
PyObject_VisitManagedDict
Line 7202 in 9ad0c7b
PyObject_ClearManagedDict
Line 7462 in 9ad0c7b
_PyObject_GetDictPtr
Line 1541 in 9ad0c7b
Non-atomic stores:
_PyObject_InitInlineValues
Lines 6787 to 6791 in 9ad0c7b
IIUC mixing of non-atomic loads/stores with atomic ones may lead to data races.
memory_order_acquire
loads:
_PyObject_GetManagedDict
cpython/Include/internal/pycore_object.h
Lines 932 to 936 in 9ad0c7b
memory_order_release
stores:
_PyObject_MaterializeManagedDict_LockHeld
Lines 6827 to 6829 in 9ad0c7b
store_instance_attr_lock_held
Lines 6925 to 6927 in 9ad0c7b
ensure_managed_dict
Lines 7494 to 7495 in 9ad0c7b
memory_order_seq_cst
stores:
set_dict_inline_values
Line 7225 in 9ad0c7b
try_set_dict_inline_only_or_other_dict
Lines 7252 to 7253 in 9ad0c7b
replace_dict_probably_inline_materialized
Lines 7287 to 7289 in 9ad0c7b
IIUC mixing acquire/release with seq_cst may break total order of seq_cst operations.
Mixing with memory_order_seq_cst
stores
_PyObject_SetManagedDict
Lines 7356 to 7365 in 9ad0c7b
_PyObject_SetManagedDict
uses non-atomic load but stores with seq_cst
mode so it is OK (IIUC), but following store without fence may lead to data race.
Are my findings valid or am I completely wrong?
CPython versions tested on:
CPython main branch
Operating systems tested on:
No response