Am Mittwoch, den 10.02.2021, 11:22 -0800 schrieb JF Bastien:
> 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

Ok, thank you. For objects which are atomic for their whole lifetime
there is no difference between both models. So one would need to
define additional semantics for a mix of atomic and non-atomic
accesses to the same non-atomic object. I think this can be done,
but I agree this is an important point to consider. (I guess this
is what Joseph meant.)

Best,
Martin


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