libcu++ <https://github.com/nvidia/libcudacxx> also uses embedded locks for
non-lockfree atomics.

On Tue, Feb 9, 2021 at 1:42 PM Ben Craig via Liaison <
liaison_at_[hidden]> wrote:

> > (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_[hidden]> On Behalf Of Uecker,
> > Martin via Liaison
> > Sent: Tuesday, February 9, 2021 3:36 PM
> > To: liaison_at_[hidden]; aaron_at_[hidden]
> > Cc: Uecker, Martin <Martin.Uecker_at_[hidden]>
> > 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_[hidden]
> > > 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$
> _______________________________________________
> 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/0305.php
>