This page is a snapshot from the LWG issues list, see the Library Active Issues List for more information and the meaning of NAD status.
Section: 33.5.8.2 [atomics.types.operations] Status: NAD Submitter: Jonathan Wakely Opened: 2021-09-29 Last modified: 2022-08-23
Priority: 2
View all other issues in [atomics.types.operations].
View all issues with NAD status.
Discussion:
Currently a compare_exchange will only update the expected parameter if the compare_exchange fails. This precludes unconditionally clearing the padding bits of the expected object prior to doing the compare_exchange, which complicates the implementation by requiring additional work (e.g. making a copy of the expected value and clearing the copy's padding, then copying it back to expected only if the compare_exchange fails).
We should consider whether we want to allow modifications to expected in the success case, if such modifications only affect padding bits (i.e. do not alter the value). If we want to allow it, we need to say so explicitly. The current wording does not permit modifications in the success case, and any such modification could create a data race if another thread is reading the same memory location (if it knows a priori that a compare_exchange_strong would succeed and so not write to that location).[2021-10-14; Reflector poll]
Set priority to 2 after reflector poll. Send to SG1.
This is 2426 again, but the new requirement to clear padding bits changes things.
[2022-07-06; Move to "Open" following SG1 feedback]
Allow compare_exchange to modify the expected value on success?
| SF | F | N | A | SA |
| 0 | 0 | 0 | 5 | 4 |
[2022-07-14; Move to "Tentatively NAD" following reflector poll]
[2022-08-23 Status changed: Tentatively NAD → NAD.]
Proposed resolution: