ATOMIC_*
macros as STD_ATOMIC_*
Section: 32.5 [atomics] Status: NAD Submitter: Canada Opened: 2010-08-25 Last modified: 2016-01-28
Priority: Not Prioritized
View all other issues in [atomics].
View all issues with NAD status.
Discussion:
Addresses CA-1
All ATOMIC_
... macros should be prefixed with STD_
as
in STD_ATOMIC_
... to indicate they are STD
macros as
other standard macros. The rationale that they all seem too long seems weak.
[2011-03-06: Daniel adapts suggested wording to N3242 and comments]
I suggest to declare this issue as NAD. Reason for this suggestion is, that
C1x is currently going to suggest exactly the same macros as additions to
header <stdatomic.h>
, therefore C++0x should not define a
whole new set. I'm making this suggestion with the understanding that
C1x is intending to keep in sync in this regard. For example, the most
recent
draft of C1x does contain the macro ATOMIC_ADDRESS_LOCK_FREE
which has recently been removed from the C++ working draft.
[2011-03-24]
Rationale:
C is not going to change the name of these macros, and it is important they have the same name for compatibility
Proposed resolution:
Change sub-clause 32.5.2 [atomics.syn] as indicated:
[..] // [atomics.lockfree], lock-free property #define STD_ATOMIC_CHAR_LOCK_FREE unspecified #define STD_ATOMIC_CHAR16_T_LOCK_FREE unspecified #define STD_ATOMIC_CHAR32_T_LOCK_FREE unspecified #define STD_ATOMIC_WCHAR_T_LOCK_FREE unspecified #define STD_ATOMIC_SHORT_LOCK_FREE unspecified #define STD_ATOMIC_INT_LOCK_FREE unspecified #define STD_ATOMIC_LONG_LOCK_FREE unspecified #define STD_ATOMIC_LLONG_LOCK_FREE unspecified // [atomics.types.operations.req], operations on atomic types #define STD_ATOMIC_VAR_INIT(value) see below [..]
Change 32.5.5 [atomics.lockfree] p. 1 as indicated:
#define STD_ATOMIC_CHAR_LOCK_FREE implementation-defined #define STD_ATOMIC_CHAR16_T_LOCK_FREE implementation-defined #define STD_ATOMIC_CHAR32_T_LOCK_FREE implementation-defined #define STD_ATOMIC_WCHAR_T_LOCK_FREE implementation-defined #define STD_ATOMIC_SHORT_LOCK_FREE implementation-defined #define STD_ATOMIC_INT_LOCK_FREE implementation-defined #define STD_ATOMIC_LONG_LOCK_FREE implementation-defined #define STD_ATOMIC_LLONG_LOCK_FREE implementation-defined1 The
STD_ATOMIC_..._LOCK_FREE
macros indicate the lock-free property of the corresponding atomic types, [..]
Change 99 [atomics.types.operations.req] p. 6 as indicated:
#define STD_ATOMIC_VAR_INIT(value) see below5 Remarks: The macro expands to a token sequence suitable for constant initialization an atomic variable of static storage duration of a type that is initialization-compatible with value. [ Note: This operation may need to initialize locks. — end note ] Concurrent access to the variable being initialized, even via an atomic operation, constitutes a data race. [ Example:
atomic<int> v = STD_ATOMIC_VAR_INIT(5);— end example ]
Change 32.5.10 [atomics.flag] p. 1+4 as indicated:
namespace std { [..] #define STD_ATOMIC_FLAG_INIT see below }[..] 4 The macro
STD_ATOMIC_FLAG_INIT
shall be defined in such a way that it can be used to initialize an object of typeatomic_flag
to the clear state. For a static-duration object, that initialization shall be static. It is unspecified whether an unitializedatomic_flag
object has an initial state of set or clear. [ Example:atomic_flag guard = STD_ATOMIC_FLAG_INIT;— end example ]