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