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.
It could, but I do not expect us to actually do that, at least not any time soon. This was not a random decision; it's hard to have a sharded lock table that works well on a heterogeneous system, but it's very easy to have things working correctly, regardless of what memory the atomics are in, if the locks are embedded in the object. We still don't know if we will support non-lock-free atomic_ref when we initially ship it for exactly this reason.
> On Tue, Feb 9, 2021 at 1:42 PM Ben Craig via Liaison <
> liaison@lists.isocpp.org> 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@lists.isocpp.org> On Behalf Of Uecker,
> > > Martin via Liaison
> > > Sent: Tuesday, February 9, 2021 3:36 PM
> > > To: liaison@lists.isocpp.org; aaron@aaronballman.com
> > > Cc: Uecker, Martin <Martin.Uecker@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@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@lists.isocpp.org
> > > 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@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@lists.isocpp.org
> Subscription: https://lists.isocpp.org/mailman/listinfo.cgi/liaison
> Link to this post: http://lists.isocpp.org/liaison/2021/02/0306.php