This page is a snapshot from the LWG issues list, see the Library Active Issues List for more information and the meaning of SG1 status.

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

Section: 31.8.2 [atomics.types.operations] Status: SG1 Submitter: Jonathan Wakely Opened: 2021-09-29 Last modified: 2021-10-23

Priority: 2

View other active issues in [atomics.types.operations].

View all other issues in [atomics.types.operations].

View all issues with SG1 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.

Proposed resolution: