You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Based on discussion in #113830 and elsewhere, there are situations in which we need to use an atomic operation in free-threaded builds, but do not need to use one in the default build, and do not want to introduce the potential performance overhead of an atomic operation in the default build. Since we anticipate that these situations will be common, we'd like to introduce wrappers around the functions found in cpython/atomic.h that perform the operation atomically in free-threaded builds and use the non-atomic equivalent in default builds.
To get discussion started, I propose the following:
We add a header that lives alongside cpython/pyatomic.h (pyatomic_free_threaded_wrappers.h?) that provides definitions of the wrappers.
Naming is hard. I'm not particularly in love with _ft_only_ and would love a better alternative to communicate that the operation is atomic in free-threaded builds and non-atomic in default builds.
This should be an internal-only header, so in Include/internal named pycore_xxx.h.
Let's try to keep this small and only add the functions we need instead of wrapping every function from pyatomic.h. There's a few places in dict and list (and your PR) where this will be useful, but I don't think it will be widely needed. I expect that many of the places that don't use critical sections, like PyDict_GetItemRef, will have different enough code paths for the free-threaded build that we will need to guard them with #ifdef Py_GIL_DISABLED rather than rely on these wrappers.
…115046)
These are intended to be used in places where atomics are required in
free-threaded builds but not in the default build. We don't want to
introduce the potential performance overhead of an atomic operation in the
default build.
Feature or enhancement
Proposal:
Based on discussion in #113830 and elsewhere, there are situations in which we need to use an atomic operation in free-threaded builds, but do not need to use one in the default build, and do not want to introduce the potential performance overhead of an atomic operation in the default build. Since we anticipate that these situations will be common, we'd like to introduce wrappers around the functions found in
cpython/atomic.h
that perform the operation atomically in free-threaded builds and use the non-atomic equivalent in default builds.To get discussion started, I propose the following:
cpython/pyatomic.h
(pyatomic_free_threaded_wrappers.h
?) that provides definitions of the wrappers.Naming is hard. I'm not particularly in love with
_ft_only_
and would love a better alternative to communicate that the operation is atomic in free-threaded builds and non-atomic in default builds.Has this already been discussed elsewhere?
No response given
Links to previous discussion of this feature:
No response
Linked PRs
The text was updated successfully, but these errors were encountered: