On Tue, Feb 9, 2021 at 10:51 PM Uecker, Martin <
Martin.Uecker_at_[hidden]> wrote:

>
>
> 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_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_[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
> > >
> >
> > _______________________________________________
> > 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