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

Billy3
From: Liaison <liaison-bounces@lists.isocpp.org> on behalf of Jens Maurer via Liaison <liaison@lists.isocpp.org>
Sent: Saturday, June 19, 2021 01:55 PM
To: Uecker, Martin <Martin.Uecker@med.uni-goettingen.de>; parallel@lists.isocpp.org <parallel@lists.isocpp.org>; liaison@lists.isocpp.org <liaison@lists.isocpp.org>
Cc: Jens Maurer <Jens.Maurer@gmx.net>
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@lists.isocpp.org
Subscription: https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.isocpp.org%2Fmailman%2Flistinfo.cgi%2Fliaison&amp;data=04%7C01%7Cbion%40microsoft.com%7C98c6ddb670ae4af04b4b08d933649c8a%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637597329498344954%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&amp;sdata=GXAEDtUygZidgL89%2F7sc%2FfC9aRrMNZRY%2BJOUE83WYMs%3D&amp;reserved=0
Link to this post: https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Flists.isocpp.org%2Fliaison%2F2021%2F06%2F0624.php&amp;data=04%7C01%7Cbion%40microsoft.com%7C98c6ddb670ae4af04b4b08d933649c8a%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637597329498344954%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&amp;sdata=Eu5H%2BNgoRn0cBxKk67NhH%2FhmvWKUE%2F9rnQ%2FJzH1yHGc%3D&amp;reserved=0