Hello,
On Fri, 28 Jul 2023, Martin Uecker wrote:
> > > Sorry, somehow I must be missing something here.
> > >
> > > If you add something you would create a new value and this may (in
> > > an object) have random new padding. But the "expected" value should
> > > be updated by a failed atomic_compare_exchange cycle and then have
> > > same padding as the value stored in the atomic. So the next cycle
> > > should succeed. The user would not change the representation of
> > > the "expected" value but create a new value for another object
> > > by adding something.
> >
> > You're right that it would pass the expected value not something after an
> > operation on it usually. But still, expected type will be something like
> > _BitInt(37) or _BitInt(195) and so neither the atomic_load nor what
> > atomic_compare_exchange copies back on failure is guaranteed to have the
> > padding bits preserved.
>
> For atomic_load in C a value is returned. A value does not care about
> padding and when stored into a new object can produce new and different
> padding.
>
> But for atomic_compare_exchange the memory content is copied into
> an object passed by pointer, so here the C standard requires to
> that the padding is preserved. It explicitely states that the effect
> is like:
>
> if (memcmp(object, expected, sizeof(*object)) == 0)
> memcpy(object, &desired, sizeof(*object));
> else
> memcpy(expected, object, sizeof(*object));
>
> > It is true that if it is larger than 16 bytes the libatomic
> > atomic_compare_exchange will memcpy the value back which copies the
> > padding bits, but is there a guarantee that the user code doesn't
> > actually copy that value further into some other variable?
>
> I do not think it would be surprising for C user when
> the next atomic_compare_exchange fails in this case.
But that is a problem (the same one the cited C++ paper tries to resolve,
IIUC). Say you have a loop like so:
_Atomic T obj;
...
T expected1, expected2, newval;
newval = ...;
expected1 = ...;
do {
expected2 = expected1;
if (atomic_compare_exchange_weak(&obj, &expected2, newval);
break;
expected1 = expected2;
} while (1);
As written this looks of course stupid, and you may say "don't do that",
but internally the copies might result from temporaries (compiler
generated or wrapper function arguments, or suchlike). Now, while
expected2 will contain the copied padding bits after the cmpxchg the
copies to and from expected1 will possibly destroy them. Either way I
don't see why the above loop should be out-of-spec, so I can write it and
expect it to proceed eventually (certainly when the _strong variant is
used). Any argument that would declare the above loop out-of-spec I would
consider a defect in the spec.
It's never a good idea to introduce reliance on padding bits. Exactly
because you can trivially destroy them with simple value copies.
> > Anyway, for smaller or equal to 16 (or 8) bytes if
> > atomic_compare_exchange is emitted inline I don't see what would
> > preserve the bits.
>
> This then seems to be incorrect for C.
Or the spec is.
Ciao,
Michael.
