Am Dienstag, den 09.02.2021, 14:08 -0800 schrieb Michał Dominiak via Liaison:
> libcu++ <https://github.com/nvidia/libcudacxx> also uses embedded locks for
> non-lockfree atomics.

At least libcu++ prominently states that there is no ABI
stability, so this could be changed, I guess.

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

Thank you! I didn't know.

I don't quite understand the explanation though. Is the reason
that there is no way to get access to a global lock shard for
the whole system so locks need to be embedded so that it works
for shared memory across processes?

Best,
Martin



> >
> >
> >
> >
> > > -----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_[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_lists.isocpp.org
> > Subscription: https://lists.isocpp.org/mailman/listinfo.cgi/liaison
> > Link to this post: http://lists.isocpp.org/liaison/2021/02/0305.php
> >
>
> _______________________________________________
> 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/0306.php