Proposed resolution:

Resolved 2011-03 Madrid meeting by paper N3278

[ Proposed Resolution ]

Change [atomics.lockfree] as indicated:

#define ATOMIC_CHAR_LOCK_FREE implementation-definedunspecified
#define ATOMIC_CHAR16_T_LOCK_FREE implementation-definedunspecified
#define ATOMIC_CHAR32_T_LOCK_FREE implementation-definedunspecified
#define ATOMIC_WCHAR_T_LOCK_FREE implementation-definedunspecified
#define ATOMIC_SHORT_LOCK_FREE implementation-definedunspecified
#define ATOMIC_INT_LOCK_FREE implementation-definedunspecified
#define ATOMIC_LONG_LOCK_FREE implementation-definedunspecified
#define ATOMIC_LLONG_LOCK_FREE implementation-definedunspecified

[ 2011-03-06: Daniel adapts the wording to N3242 ]

[ 2011-02-20: Daniel adapts the proposed wording to N3225 and fixes an editorial omission of applying N3193 ]

[ 2011-02-24 Reflector discussion ]

Moved to Tentatively Ready after 5 votes.

[ 2010-10-26: Daniel adds: ]

The proposed resolution below is against the FCD working draft. After application of the editorial issues US-144 and US-146 the remaining difference against the working draft is the usage of implementation-defined instead of unspecified, effectively resulting in this delta:

// 29.4, lock-free property
#define ATOMIC_CHAR_LOCK_FREE unspecifiedimplementation-defined
#define ATOMIC_CHAR16_T_LOCK_FREE unspecifiedimplementation-defined
#define ATOMIC_CHAR32_T_LOCK_FREE unspecifiedimplementation-defined
#define ATOMIC_WCHAR_T_LOCK_FREE unspecifiedimplementation-defined
#define ATOMIC_SHORT_LOCK_FREE unspecifiedimplementation-defined
#define ATOMIC_INT_LOCK_FREE unspecifiedimplementation-defined
#define ATOMIC_LONG_LOCK_FREE unspecifiedimplementation-defined
#define ATOMIC_LLONG_LOCK_FREE unspecifiedimplementation-defined
#define ATOMIC_ADDRESS_LOCK_FREE unspecified

It is my understanding that the intended wording should be unspecified as for ATOMIC_ADDRESS_LOCK_FREE but if this is right, we need to use the same wording in [atomics.lockfree], which consequently uses the term implementation-defined. I recommend to keep [atomics.syn] as it currently is and to fix [atomics.lockfree] instead as indicated:

[ Proposed resolution as of comment ]

Against FCD, N3092:

In [atomics.syn], header <atomic> synopsis replace as indicated:

// 29.4, lock-free property
#define ATOMIC_INTEGRAL_LOCK_FREE unspecified
#define ATOMIC_CHAR_LOCK_FREE implementation-defined
#define ATOMIC_CHAR16_T_LOCK_FREE implementation-defined
#define ATOMIC_CHAR32_T_LOCK_FREE implementation-defined
#define ATOMIC_WCHAR_T_LOCK_FREE implementation-defined
#define ATOMIC_SHORT_LOCK_FREE implementation-defined
#define ATOMIC_INT_LOCK_FREE implementation-defined
#define ATOMIC_LONG_LOCK_FREE implementation-defined
#define ATOMIC_LLONG_LOCK_FREE implementation-defined
#define ATOMIC_ADDRESS_LOCK_FREE unspecified

Addresses GB-130

The synopsis for the <atomic> header lists the macros ATOMIC_INTEGRAL_LOCK_FREE and ATOMIC_ADDRESS_LOCK_FREE.

The ATOMIC_INTEGRAL_LOCK_FREE macro has been replaced with a set of macros for each integral type, as listed in [atomics.lockfree].