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

I really want to a have a complete formal model of C.

But at the moment C atomics are not usable for many
projects because this mix is not possible.

It is simply not realistic to add unnecessary copies
from double arrays to atomic double arrays in
computational intensive numerical code.

So the priorities are clear to me.

Best,
Martin



> 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]g
> > > > Subscription: https://lists.isocpp.org/mailman/listinfo.cgi/liaison
> > > > Link to this post: http://lists.isocpp.org/liaison/2021/02/0322.php
> > > >