Am Dienstag, den 09.02.2021, 13:02 -0800 schrieb Hans Boehm via Liaison:
> The papers that I mentioned that it would be really nice to discuss here
> are:
>
> wg21.link/p0943 - This has been adopted by wg21 in November. It assumes
> that we want _Atomic() and std::atomic<> to be synonymous in C++, which
> really only makes sense if _Atomic() has similar semantics in C. In
> particular, this gets questionable if C constrained _Atomic(T) to have the
> same alignment/size as T. That issue interacts with the type qualifier vs.
> specifier _Atomic issue in C. It would be nice to discuss this soon, since
> this probably has implications for both C++23 and C23. (A fallback here
> would be to remove _Atomic from the common subset and to limit that to
> atomic_int and friends. But that would be unfortunate.)

I was thinking about writing a paper about this for WG14.

I really believe that _Atomic T should be compatible
to T. In my opinion this would fix a major problem of
atomics C.

Unfortunately, changing the alignment is an ABI breaking
change so it is unlikely to happen. But requiring at least
the same size and representation could be reasonable, if
this is also acceptable for C++ (I am not aware of any
implementation that actually inserts locks into atomic
types).

_Atomic(T) should definitely stay compatible to C++.
I think being able to write header that are compatible
between C and C++ is really one of the more important
issues the study group should address.

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

>
> wg21.link/p1478 - Byte-wise atomic memcpy. Much more esoteric, and less
> urgent. This is on track for adoption into a C++ TS. But given that it is
> C-like functionality, it would be good to understand WG14's opinion. Though
> esoteric, it seems to be functionality that we're otherwise lacking, and
> that many performance-sensitive systems eventually need. WG21 has
> repeatedly reinvented it in different forms.
>
> There are of course also various memory model efforts going on in a
> combination of WG14 and WG21 (out-of-thin-air, memory_order_consume
> replacement, pointer zap, provenance). Much of this is still exploratory at
> this stage, and is probably mostly OK the way it is? It will clearly have
> to affect both languages in the end, since these end up fundamentally
> affecting compiler back end assumptions.

Yes, also: effective types.

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/0303.php