> (I am not aware of any implementation that actually inserts locks into atomic types).
The MSVC implementation inserts locks into types that aren't lock-free. There is no global singleton that their C runtime can use. On most unix-like OSes, a global singleton lock shard is easier to implement.





> -----Original Message-----
> From: Liaison <liaison-bounces_at_lists.isocpp.org> On Behalf Of Uecker,
> Martin via Liaison
> Sent: Tuesday, February 9, 2021 3:36 PM
> To: liaison_at_[hidden]; aaron_at_aaronballman.com
> Cc: Uecker, Martin <Martin.Uecker_at_med.uni-goettingen.de>
> Subject: [EXTERNAL] Re: [wg14/wg21 liaison] Atomics papers
>
> 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_lists.isocpp.org
> > Subscription:
> > https://urldefense.com/v3/__https://lists.isocpp.org/mailman/listinfo.
> > cgi/liaison__;!!FbZ0ZwI3Qg!6ZvL1ROH5JraHZ-vqqtztd-g2pWOMkj7gkHf-
> pV4VUq
> > It_oK_FO3wPu4ZX4g$ Link to this post:
> > https://urldefense.com/v3/__http://lists.isocpp.org/liaison/2021/02/03
> > 03.php__;!!FbZ0ZwI3Qg!6ZvL1ROH5JraHZ-vqqtztd-g2pWOMkj7gkHf-
> pV4VUqIt_oK
> > _FO3wNPbgD6v$
> _______________________________________________
> Liaison mailing list
> Liaison_at_[hidden]
> Subscription:
> https://urldefense.com/v3/__https://lists.isocpp.org/mailman/listinfo.cgi/lia
> ison__;!!FbZ0ZwI3Qg!6ZvL1ROH5JraHZ-vqqtztd-g2pWOMkj7gkHf-
> pV4VUqIt_oK_FO3wPu4ZX4g$
> Link to this post:
> https://urldefense.com/v3/__http://lists.isocpp.org/liaison/2021/02/0304.p
> hp__;!!FbZ0ZwI3Qg!6ZvL1ROH5JraHZ-vqqtztd-g2pWOMkj7gkHf-
> pV4VUqIt_oK_FO3wCY4ZQWZ$