- attached atomic_probe.sh
RFE: atomics for more integral types
Currently we support atomics only on (u)int{32,64}_t
, plus float
and double
.
We notably do not support size_t
, (u)intptr_t
, ptrdiff_t
and similar.
We have previously determined that:
- Some platforms use (for instance)
typedef unsigned long long uint64_t
andtypedef unsigned long size_t
, such thatsize_t
does not map to any of the supported types. - Simply implementing the template specialization for all of these types results in multiply-defined problems.
Now that we have a configure script, it is technically feasible to probe the type system to construct a list of the "non-overlapping" types (e.g. both uint64_t
and size_t
in the example above).
Comments (5)
-
reporter -
reporter -
assigned issue to
Initial implementation in pull request 167
-
assigned issue to
-
-
assigned issue to
This was discussed in the 2020-02-12 meeting
I'm taking assignment to deploy the proposed improved design as time allows
-
assigned issue to
-
Proposed solution in pull request #172
-
- changed status to resolved
Re-implement atomic_domain interface to GASNet
- atomic_domain<T> now supports T = any 32/64-bit integer type,
no longer restricted to
std::(u)int{32,64}_t
. This means it's now portable and safe to use things likeatomic_domain<long>
oratomic_domain<size_t>
. Fixes issue#298. - Leverage the dependency-free <gasnet_fwd.h> header (introduced in 2018.6.0) to enable direct use of GEX_OP_, GEX_DT_, GEX_FLAG_* and gex_Event_t in the public header, without pulling in all of GASNet.
- Remove a redundant gex_Event_Test() operation
Overall this change includes removal of a table lookup and several branches that were previously in the critical path of AMO injection (for normal opt-mode builds not using LTO). This is expected to provide measureable improvement to the overhead of AMO injection using the PSHM bypass path (local_team peers).
→ <<cset 5bd872b8c145>>
- Log in to comment
The attachment is a simple proof-of-concept for the required configure probe. It determines which of a list of predefined types are 32 or 64 bits, NOT typedefs for the same underlying types as
(u)int{32,64}_t
, and NOT a typedef for the same underlying type as any type the probe has already identified as distinct.To illustrate the motivation for this, note how the following Linux and macOS outputs (both x86_64) differ due to their differing definitions of
(u)int64_t
:Linux:
macOS: