Am Mittwoch, den 10.02.2021, 20:24 +0000 schrieb Joseph Myers:
> On Wed, 10 Feb 2021, Uecker, Martin via Liaison wrote:
>
> > > 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.
>
> My point is that you could allow atomic_store, atomic_compare_exchange
> etc. generic functions from stdatomic.h to be called where the type shown
> as A is not an atomic type, so allowing a mixture of atomic and non-atomic 
> operations on the same object, without having an atomic qualifier at all.
> Or you could have new generic functions that do the same as the existing
> ones but on non-atomic types, again without needing an atomic qualifier.

This is basically what I am doing now in my code using
OpenMP atomics. We could add such functions.
The disadvantage is the lack of type safety.

Similar to the const qualifier it would be useful to
be able to convert a pointer to add the atomic qualifer
and then get a compile time error if non-atomic
operations are used.

Best,
Martin