Anthony,

on Thu, 15 Apr 2021 08:44:38 +0100 you (Anthony Williams via Liaison
<liaison_at_[hidden]>) wrote:

> Atomic atomic;
> Padded some_value=init();
>
> Thread 1:
> atomic=some_value;
>
> Thread 2:
> Padded local=some_value;
> Padded new_value=whatever();
>
> if(atomic->compare_exchange_strong(local,new_value))
> do_stuff();
>
>
> Note this is an "if", not a "while" --- I am checking to see if
> thread 1 did its write before thread 2 or after.
>
> If padding bits are counted in the comparison, then the compare may
> not succeed, even if the value is the expected one, because the
> padding bits in "local" might not match those in "some_value", or the
> padding bits written to "atomic".

Yes, that might not succeed, but the control flow never has an
ambiguity so there is no UB or something like that.

> For padding bits to count in the comparison in
> compare_exchange_strong, we must ensure that they are preserved
> everywhere.

I am not sure of that, I find it acceptable that the above fails for
structure types with padding. But it should work if the assignment is
replaced by a `memcpy`, this is the equality relation that is thought,
here.

  Padded local;
  memcpy(&local, &some_value, sizeof local);

Or even if we later compare representations, such as in

          do {
             if(atomic->compare_exchange_strong(local,new_value))
                do_stuff();
          } while (!memcmp(&local, &some_value, sizeof local));


> C++ explicitly does not preserve them, so they cannot be part of the
> comparison. C can make a different choice.

Thanks
Jens

-- 
:: INRIA Nancy Grand Est ::: Camus ::::::: ICube/ICPS :::
:: ::::::::::::::: office Strasbourg : +33 368854536   ::
:: :::::::::::::::::::::: gsm France : +33 651400183   ::
:: ::::::::::::::: gsm international : +49 15737185122 ::
:: http://icube-icps.unistra.fr/index.php/Jens_Gustedt ::