Should compare_exchange be allowed to modify the expected value on success?
Jonathan Wakely

Created on 2021-09-29.00:00:00 last changed 1 month ago


Date: 2021-10-15.00:00:00

[ 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.

Date: 2021-09-29.00:00:00

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).

Date User Action Args
2021-10-14 11:35:22adminsetmessages: + msg12146
2021-10-14 11:35:22adminsetstatus: new -> open
2021-09-29 00:00:00admincreate