Proposed resolution:

1. Change sub-clause [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
   [..]
   

2. Change [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-defined
   

   1 The STD_ATOMIC_..._LOCK_FREE macros indicate the lock-free property of the corresponding atomic types, [..]

3. Change [atomics.types.operations.req] p. 6 as indicated:

   #define STD_ATOMIC_VAR_INIT(value) see below
   

   5 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 ]

4. Change [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 type atomic_flag to the clear state. For a static-duration object, that initialization shall be static. It is unspecified whether an unitialized atomic_flag object has an initial state of set or clear. [ Example:

   atomic_flag guard = STD_ATOMIC_FLAG_INIT;
   

   — end example ]

[ 2011-03-24 ]

[ 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.

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.