On Wed, Feb 10, 2021 at 11:17 AM Uecker, Martin via Liaison <
liaison_at_[hidden]> wrote:

> Am Mittwoch, den 10.02.2021, 18:51 +0000 schrieb Joseph Myers:
> > On Wed, 10 Feb 2021, Uecker, Martin via Liaison wrote:
> >
> > > > Whatever system you might add for atomic operations on non-atomic
> data, I
> > > > think making the syntactic-qualifier _Atomic into something
> semantically a
> > > > qualifier would be an unreasonably incompatible way of adding such a
> > > > feature.
> > >
> > > A qualifier is exactly what is needed if you want to
> > > express atomic operations on non-atomic data as it has
> > > exactly the right right semantics. Qualifiers affect
> >
> > You need the various *operations* from stdatomic.h in forms that can be
> > applied to non-atomic data.
>
> I am not sure I understand what you mean.
>
> On a fundamental level on architectures supported by C there
> is no atomic or non-atomic memory. Only accesses are atomic or
> not (this is why a qualifier is a natural choice for "lockless"
> accesses). So having the qualifier would imply atomic accesses
> and not having the qualifier would imply accesses which may
> be not atomic. We support atomic for all types, so we need
> a fallback mechanism if the hardware can not do a "lockless"
> access.
>

This is correct, but the C and C++ memory models talk about atomicity for
objects, not for accesses. Even atomic_ref fits in this model by having
"epochs" for accesses being atomic and non-atomic. There are advantages to
the per-access model, as well as for the per-object model. IMO it's
important to internalize those advantages before deciding to modify or add
capabilities to atomic. Unfortunately this isn't documented in a central
location, maybe this paper is the best start:
https://www.cl.cam.ac.uk/~pes20/cpp/popl085ap-sewell.pdf


But I probably missed your point.
>
> > Whether you need to be able to use the cases
> > of direct assignment implying seq_cst for atomic accesses to non-atomic
> > data, or just the operations in stdatomic.h, seems less clear to me.
> >
> > (I realise that some things that can be done with direct assignment
> > operators have no corresponding stdatomic.h operations; for example,
> > atomic compound assignment for floating-point types with all the
> > corresponding implications for handling floating-point exception state.
> > However, such operations could be added to stdatomic.h, so allowing an
> > explicit memory order to be specified, independent of any way to apply
> > atomic operations to non-atomic data.)
> >
> > > If the problem is only alignment, then I think this could
> > > be made backwards compatible (as pointed out in my
> > > other email).
> >
> > Alignment differences imply size differences once you include the atomic
> > object into a larger struct.
>
> A struct having an atomic member is not compatible to the
> same struct having the corresponding type as non-atomic
> member. So adding some padding and increasing the size
> of the struct would still be ok for a compiler to do
> even when we required T and _Atomic T to have the same
> representation. Such structs could then stay compatible.
>
> > (And I think some implementations may e.g.
> > enlarge _Atomic struct { char x[3]; } to 4 bytes, adding padding in
> order
> > to increase its alignment.)
>
> Yes, some change size and alignment of this struct.
> But this is incompatible to others. So some compilers
> need to make an ABI breaking change anyway. If we
> required _Atomic T and T to have the same
> representation then this ABI is fixed and it clear
> what needs to be changed. If not, somebody else
> needs to decide which is the right ABI. Apparently
> nobody did this in the last decade.
>
> Best,
> Martin
>
>
>
> _______________________________________________
> Liaison mailing list
> Liaison_at_[hidden]
> Subscription: https://lists.isocpp.org/mailman/listinfo.cgi/liaison
> Link to this post: http://lists.isocpp.org/liaison/2021/02/0322.php
>