This page is a snapshot from the LWG issues list, see the Library Active Issues List for more information and the meaning of C++23 status.
Section: 32.5.5 [atomics.lockfree] Status: C++23 Submitter: Billy O'Neal III Opened: 2019-08-03 Last modified: 2023-11-22
Priority: 4
View all other issues in [atomics.lockfree].
View all issues with C++23 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 32.5.5 [atomics.lockfree] as indicated:
-2- The functions
atomic<T>::is_lock_free
, andatomic_is_lock_free
(32.5.8.2 [atomics.types.operations]) indicateswhether 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.