On Wed, Feb 10, 2021 at 11:41 AM Uecker, Martin <
Martin.Uecker_at_[hidden]> wrote:

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

Correct. Doing this is complex and still an active area of research,
because it's tricky to have a mathematical model of possible outcomes when
mixing atomic and non-atomic.

Interestingly, JavaScript is ahead of C and C++ on this topic:
https://arxiv.org/abs/1801.10140

An extra complexity comes up when we allow mixed-sized accesses, including
potentially unaligned ones. The hardware vendors have done interesting
research on these models.



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