Am Dienstag, den 09.02.2021, 15:36 -0800 schrieb Hans Boehm via Liaison:
> On Tue, Feb 9, 2021 at 2:57 PM Joseph Myers via Liaison <
> liaison_at_[hidden]> wrote:
>
> > On Tue, 9 Feb 2021, Uecker, Martin via Liaison wrote:
> >
> > > One way forward for C could be to decouple the qualifier
> > > and the specifier and make casts of non-atomic types
> > > possible. _Atomic(T) would then be an _Atomic-qualified
> > > type which has additional properties not implied by
> > > the qualifier (stricter alignment) and which is compatible
> > > to C++.
> >
> > Since the two forms of _Atomic are just alternative notation for writing
> > the same type (and so are the atomic_* names in stdatomic.h), changing
> > that now would be clearly incompatible with existing code and I think very
> > much a bad idea.

If _Atomic T and T have the same representation, then
I don't think this is necessarily the case. You can
make all _Atomic T and _Atomic(T) variables have the
same alignment and be compatible then existing code
still works. The difference would be that a pointer
to an _Atomic qualified type would not imply optimal
alignment and the compiler would need to fall back
to calling a library routine, while a pointer to
_Atomic(T) would imply optimal alignment and the
compiler can (sometimes) directly use lockfree
atomics without callling the library.

If course, for Atomic types with different representation
(including locks) this would not work.

> > We've had similar discussions before on the WG14 reflector. The concern
>
> here is basically that if _Atomic were to be usable as a real type
> qualifier that can be added to parameters, then _Atomic T and T should have
> the same representation. But T and std::atomic<T> can't reasonably always
> have the same representation, since that would force locks to be used where
> they are avoidable, which certainly many of us agree is a bad thing.

You would need have a run-time check for alignment to use the
lockfree type and only if the compiler can't determine the
alignment by static analysis (e.g. member in a struct or local
variables would be fine). And as I understand it, this would
affect only very few types.

> So we can't have _Atomic T both work as a proper qualifier and be the same
> as std::atomic<T>. I think C really wants the type qualifier to work, since
> it doesn't have atomic_ref<>. So something has to give, and we've had
> different proposals about what that should be.

The last resort could be to deprecate the _Atomic pseudo-qualifier
and introduce a new one with a different name

> A further complication (or simplification, depending on how you look at it)
> is that the ABI story here is currently badly broken for everything but
> simple types with size == alignment. The upside is that we can probably
> change more than one might expect, so long as we leave the simple (and by
> far most common) case alone. Everything else is largely broken and
> hopefully unused anyway.
>
> All of which is an argument to properly discuss this at a meeting ...

Best,
Martin


> Hans
> _______________________________________________
> 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/0308.php