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.

### 3611. Should `compare_exchange` be allowed to modify the `expected` value on success?

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: