[issue31473] PyMem_Raw* API in debug mode are not thread safe

STINNER Victor added the comment: Note: PTHREAD_MUTEX_INITIALIZER can be used to statically initialize a mutex. -- ___ Python tracker ___ _

[issue31473] PyMem_Raw* API in debug mode are not thread safe

STINNER Victor added the comment: By the way, the previous attempt to add _PyRuntime.mem had to be reverted. See bpo-32096, bpo-30860 and the commit: commit 9e87e7776f7ace66baaf7247233afdabd00c2b44 Author: Victor Stinner Date: Fri Nov 24 12:09:24 2017 +0100 bpo-32096: Remove obj and m

[issue31473] PyMem_Raw* API in debug mode are not thread safe

STINNER Victor added the comment: See also bpo-35265: "Internal C API: pass the memory allocator in a context". The most complex part is the Python initialization which changes the memory allocator *and* allocate memory. We have to remain which allocator has been used to allocate data, to be

[issue31473] PyMem_Raw* API in debug mode are not thread safe

STINNER Victor added the comment: I looked at _Py_atomic_address to avoid atomic "serialno++", but we don't have atomic_fetch_add(). We could implement it using a loop and atomic_compare_exchange_strong()... but we don't have atomic_compare_exchange_strong() neither. I tried to add a mutex,

[issue31473] PyMem_Raw* API in debug mode are not thread safe

New submission from Xiang Zhang: PyMem_Raw* APIs should be thread safe. But in debug mode, they are not that simple and increment a global variable *serialno* and the incrementing action is not thread safe. -- components: Interpreter Core messages: 302187 nosy: haypo, xiang.zhang prior