Section: 32.5.2 [atomics.syn] Status: Resolved Submitter: BSI Opened: 2010-08-25 Last modified: 2016-01-28
Priority: Not Prioritized
View other active issues in [atomics.syn].
View all other issues in [atomics.syn].
View all issues with Resolved status.
Discussion:
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 32.5.5 [atomics.lockfree].
[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
[ 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_FREEunspecifiedimplementation-defined #define ATOMIC_CHAR16_T_LOCK_FREEunspecifiedimplementation-defined #define ATOMIC_CHAR32_T_LOCK_FREEunspecifiedimplementation-defined #define ATOMIC_WCHAR_T_LOCK_FREEunspecifiedimplementation-defined #define ATOMIC_SHORT_LOCK_FREEunspecifiedimplementation-defined #define ATOMIC_INT_LOCK_FREEunspecifiedimplementation-defined #define ATOMIC_LONG_LOCK_FREEunspecifiedimplementation-defined #define ATOMIC_LLONG_LOCK_FREEunspecifiedimplementation-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 32.5.5 [atomics.lockfree], which consequently uses
the term implementation-defined. I recommend to keep 32.5.2 [atomics.syn] as it currently is and to
fix 32.5.5 [atomics.lockfree] instead as indicated:
[2011-02-24 Reflector discussion]
Moved to Tentatively Ready after 5 votes.
[2011-02-20: Daniel adapts the proposed wording to N3225 and fixes an editorial omission of applying N3193]
[2011-03-06: Daniel adapts the wording to N3242]
[Proposed Resolution]
Change 32.5.5 [atomics.lockfree] as indicated:
#define ATOMIC_CHAR_LOCK_FREEimplementation-definedunspecified #define ATOMIC_CHAR16_T_LOCK_FREEimplementation-definedunspecified #define ATOMIC_CHAR32_T_LOCK_FREEimplementation-definedunspecified #define ATOMIC_WCHAR_T_LOCK_FREEimplementation-definedunspecified #define ATOMIC_SHORT_LOCK_FREEimplementation-definedunspecified #define ATOMIC_INT_LOCK_FREEimplementation-definedunspecified #define ATOMIC_LONG_LOCK_FREEimplementation-definedunspecified #define ATOMIC_LLONG_LOCK_FREEimplementation-definedunspecified
Proposed resolution:
Resolved 2011-03 Madrid meeting by paper N3278