Non-lock-free atomic<T> or atomic_ref<T> is a portability fallback, not a viable mode of operation.
@pcordes mentioned this on SO answer https://stackoverflow.com/a/61996697/2945027
Also @BillyONeal mentioned in https://github.com/microsoft/STL/issues/668#issuecomment-608074371:
atomic<more than 16 bytes>is supported on nothing, so it really isn't dovetailing into that design goal, it's an accident.
So I guess it is some well accepted fact.
It may make sense to issue a warning for instantiating never-lock-free atomics.
Probably never-lock-free should be defined for this warning in terms of Future New ABI, where limitations are only hardware limitations, not ABI-specific implementation limitations, specifically excluding those:
cmpxchg16b detection)atomic<T> has padding, and always lock freeSo effectively I suggest emitting a warning for:
atomic<T> if sizeof(T) > sizeof(void*)*2atomic_ref<T> if sizeof(T) > sizeof(void*)*2 || !has_single_bit(sizeof(T))The STL doesn't have a good mechanism for emitting warnings other than deprecation warnings.
So is it blocked on compiler to implement intrinsic for that?
We would need to request an attribute or something from the codegen compilers (MSVC and Clang), at the very least. Some design would probably be necessary, since our tools for suppressing warnings are otherwise just macros, which aren't very usable (they're barely tolerable for deprecations and removals).
I would prefer something with __assume-like behavior. Including following cases:
#ifndef _STL_SUPPRESS_WARNING_STORAGE_BASE_TEMPLATE
__warn(
false,
"STL4034: Should avoid going this branch or instantiating this template"
"Define _STL_SUPPRESS_WARNING_STORAGE_BASE_TEMPLATE to suppress");
#endif
#ifndef _STL_SUPPRESS_WARNING_MISALIGN_REF
__warn(
alignof(_Ty) < sizeof(_Ty),
"STL4035: Should avoid this type for atomic_ref template parameter. "
"Define _STL_SUPPRESS_WARNING_MISALIGN_REF to suppress");
#endif
Attribute is convenient for deprecation. And even for deprecation it is not always convenient.
I don't think this static_assert(true, "Never fails") is something clear:
https://github.com/microsoft/STL/blob/212de15c590010c961c0e7bb4025f6fec89866c8/stl/inc/yvals_core.h#L964-L973
https://github.com/microsoft/STL/blob/212de15c590010c961c0e7bb4025f6fec89866c8/stl/inc/atomic#L1173-L1177
https://github.com/microsoft/STL/blob/212de15c590010c961c0e7bb4025f6fec89866c8/stl/inc/atomic#L1546-L1550
Macro is ok, though another parameter with number to suppress would be better.
I don't think it's a good idea for us to require users to jump through hoops to silence a warning telling them that something is correct but may not be as fast as they'd like. This seems eerily reminiscent of our old friend _CRT_SECURE_NO_WARNINGS: I don't want to be in the business of telling users they should feel bad for using parts of the library that we don't like.
We talked about this in the weekly maintainers meeting and we believe that this is both out of scope for the project, and constrained by available technology for delivering library warnings. We might reconsider this in the future, but for now, we don't plan to add such performance warnings.
Most helpful comment
I don't think it's a good idea for us to require users to jump through hoops to silence a warning telling them that something is correct but may not be as fast as they'd like. This seems eerily reminiscent of our old friend
_CRT_SECURE_NO_WARNINGS: I don't want to be in the business of telling users they should feel bad for using parts of the library that we don't like.