This page is a snapshot from the LWG issues list, see the Library Active Issues List for more information and the meaning of WP status.
Section: 33.5.5 [atomics.lockfree] Status: WP Submitter: Billy O'Neal III Opened: 2019-08-03 Last modified: 2020-11-09
Priority: 4
View all other issues in [atomics.lockfree].
View all issues with WP status.
Discussion:
According to SG1 experts, the requirement in [atomics.lockfree]/2 is intended to require that the answer for is_lock_free() be the same for a given T for a given run of the program. The wording does not achieve that because it's described in terms of 'pointers', but there are no pointers in an atomic<int>.
[2020-02 Status to Ready on Thursday morning in Prague.]
[2020-11-09 Approved In November virtual meeting. Status changed: Ready → WP.]
Proposed resolution:
This wording is relative to N4830.
Modify 33.5.5 [atomics.lockfree] as indicated:
-2- The functions atomic<T>::is_lock_free, and atomic_is_lock_free (33.5.8.2 [atomics.types.operations]) indicate
swhether the object is lock-free. In any given program execution, the result of the lock-free query is the same for all atomic objectsshall be consistent for all pointersof the same type.