This page is a snapshot from the LWG issues list, see the Library Active Issues List for more information and the meaning of Resolved status.

1457. Splitting lock-free properties

Section: 33.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.


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 33.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_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 33.5.5 [atomics.lockfree], which consequently uses the term implementation-defined. I recommend to keep 33.5.2 [atomics.syn] as it currently is and to fix 33.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 33.5.5 [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

Proposed resolution:

Resolved 2011-03 Madrid meeting by paper N3278