Date: Mon, 21 Jun 2021 20:18:25 +0000
Am Montag, den 21.06.2021, 19:49 +0000 schrieb Billy O'Neal (VC LIBS):
> > It would be the ABI group's job to ensure that C's hypothetical "_Atomic T *" is equivalent to
> > C++'s std::atomic_ref<T>.
>
> On our implementation atomic_ref and atomic share ~nothing in common, because we want the lower
> level construct, atomic, to work across library / linkage boundaries, which forbids the 'external
> lock table' implementation. (2 different DLLs which link different CRTs have no means to
> coordinate on where the lock table lives)
>
> I hope WG14 understands that mandating the external lock table implementation in more places isn't
> a practical result for some implementations.
The idea would be to leave _Atomic(T) alone and compatible to C++.
So these types could still contain a lock.
In C atomic_ref<T> could then be a qualifier (but more likely
with a new name). So it would be the same as in C++
only using syntax that is a better fit for C.
Martin
> Billy3
> ________________________________
> From: Liaison <liaison-bounces_at_[hidden]cpp.org> on behalf of Jens Maurer via Liaison <
> liaison_at_lists.isocpp.org>
> Sent: Saturday, June 19, 2021 01:55 PM
> To: Uecker, Martin <Martin.Uecker_at_[hidden]gen.de>; parallel_at_lists.isocpp.org <
> parallel_at_[hidden]ocpp.org>; liaison_at_lists.isocpp.org <liaison_at_lists.isocpp.org>
> Cc: Jens Maurer <Jens.Maurer_at_[hidden]>
> Subject: Re: [wg14/wg21 liaison] [isocpp-parallel] atomics in C++
>
> On 19/06/2021 22.49, Uecker, Martin wrote:
> > Since _Atomic_ref(T) is basically a pointer the
> > corresponding C type would then be _Atomic T*.
> >
> > But would we need to wrap it into a struct
> > for ABI compatibility?
>
> It would be the ABI group's job to ensure that C's
> hypothetical "_Atomic T *" is equivalent to C++'s
> std::atomic_ref<T>.
> For x86-64, I think there is no difference between
> a plain pointer and a pointer wrapped in a struct
> (as its single member). If an ABI makes a difference
> here, it would need to carve out a special case for
> "_Atomic T *".
> > > The question is whether we can/should/want to have a standard-based
> > > compatibility story for "atomic reference" or not.
> > > We've recently made "_Atomic(T)" the compatibility advice
> > > for atomic types in code shared between C and C++. Good.
> >
> > I am am also not sure. For me _Atomic_ref would be something
> > used mainly internally in a library, e.g. where an
> > external interface passes a data structure without atomic
> > types and then the library wants to apply a concurrent
> > algorithm on the existing data structure.
>
> Maybe the -parallel group of WG21 has some opinion here.
>
> Jens
>
> _______________________________________________
> Liaison mailing list
> Liaison_at_[hidden]
> Subscription:
> https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.isocpp.org%2Fmailman%2Flistinfo.cgi%2Fliaison&data=04%7C01%7Cbion%40microsoft.com%7C98c6ddb670ae4af04b4b08d933649c8a%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637597329498344954%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=GXAEDtUygZidgL89%2F7sc%2FfC9aRrMNZRY%2BJOUE83WYMs%3D&reserved=0
> Link to this post:
> https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Flists.isocpp.org%2Fliaison%2F2021%2F06%2F0624.php&data=04%7C01%7Cbion%40microsoft.com%7C98c6ddb670ae4af04b4b08d933649c8a%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637597329498344954%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=Eu5H%2BNgoRn0cBxKk67NhH%2FhmvWKUE%2F9rnQ%2FJzH1yHGc%3D&reserved=0
> > It would be the ABI group's job to ensure that C's hypothetical "_Atomic T *" is equivalent to
> > C++'s std::atomic_ref<T>.
>
> On our implementation atomic_ref and atomic share ~nothing in common, because we want the lower
> level construct, atomic, to work across library / linkage boundaries, which forbids the 'external
> lock table' implementation. (2 different DLLs which link different CRTs have no means to
> coordinate on where the lock table lives)
>
> I hope WG14 understands that mandating the external lock table implementation in more places isn't
> a practical result for some implementations.
The idea would be to leave _Atomic(T) alone and compatible to C++.
So these types could still contain a lock.
In C atomic_ref<T> could then be a qualifier (but more likely
with a new name). So it would be the same as in C++
only using syntax that is a better fit for C.
Martin
> Billy3
> ________________________________
> From: Liaison <liaison-bounces_at_[hidden]cpp.org> on behalf of Jens Maurer via Liaison <
> liaison_at_lists.isocpp.org>
> Sent: Saturday, June 19, 2021 01:55 PM
> To: Uecker, Martin <Martin.Uecker_at_[hidden]gen.de>; parallel_at_lists.isocpp.org <
> parallel_at_[hidden]ocpp.org>; liaison_at_lists.isocpp.org <liaison_at_lists.isocpp.org>
> Cc: Jens Maurer <Jens.Maurer_at_[hidden]>
> Subject: Re: [wg14/wg21 liaison] [isocpp-parallel] atomics in C++
>
> On 19/06/2021 22.49, Uecker, Martin wrote:
> > Since _Atomic_ref(T) is basically a pointer the
> > corresponding C type would then be _Atomic T*.
> >
> > But would we need to wrap it into a struct
> > for ABI compatibility?
>
> It would be the ABI group's job to ensure that C's
> hypothetical "_Atomic T *" is equivalent to C++'s
> std::atomic_ref<T>.
> For x86-64, I think there is no difference between
> a plain pointer and a pointer wrapped in a struct
> (as its single member). If an ABI makes a difference
> here, it would need to carve out a special case for
> "_Atomic T *".
> > > The question is whether we can/should/want to have a standard-based
> > > compatibility story for "atomic reference" or not.
> > > We've recently made "_Atomic(T)" the compatibility advice
> > > for atomic types in code shared between C and C++. Good.
> >
> > I am am also not sure. For me _Atomic_ref would be something
> > used mainly internally in a library, e.g. where an
> > external interface passes a data structure without atomic
> > types and then the library wants to apply a concurrent
> > algorithm on the existing data structure.
>
> Maybe the -parallel group of WG21 has some opinion here.
>
> Jens
>
> _______________________________________________
> Liaison mailing list
> Liaison_at_[hidden]
> Subscription:
> https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.isocpp.org%2Fmailman%2Flistinfo.cgi%2Fliaison&data=04%7C01%7Cbion%40microsoft.com%7C98c6ddb670ae4af04b4b08d933649c8a%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637597329498344954%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=GXAEDtUygZidgL89%2F7sc%2FfC9aRrMNZRY%2BJOUE83WYMs%3D&reserved=0
> Link to this post:
> https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Flists.isocpp.org%2Fliaison%2F2021%2F06%2F0624.php&data=04%7C01%7Cbion%40microsoft.com%7C98c6ddb670ae4af04b4b08d933649c8a%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637597329498344954%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=Eu5H%2BNgoRn0cBxKk67NhH%2FhmvWKUE%2F9rnQ%2FJzH1yHGc%3D&reserved=0
Received on 2021-06-21 15:18:33