CC'ing in the fine folks from SG1, who deal with concurrency and
parallelism in WG21, as they likely have good details to share here.

~Aaron

On Sat, Jun 19, 2021 at 7:17 AM Uecker, Martin via Liaison
<liaison_at_[hidden]> wrote:
>
>
> Hi all,
>
> I want to summarize my understanding of the compatibility situation
> for atomics here because I want to write a paper for WG14 addressing
> potential solutions for the _Atomic_ref use case in C, and want
> to make sure I get this part right.
>
> For compatibility, there are two things required:
>
> 1. Compatible syntax for headers
> 2. ABI compatibility
>
> Regarding the first point, in C we have the atomic_XXX types and
> also the _Atomic(T) type specifier (C11), which were both designed
> together with WG21 with compatibility in mind. The only thing which
> still was missing is the _Atomic(T) macro in C++. This seems now part
> of C23++ [1]. So the compatibility story seems finally complete
> and we can now write things like this (thank you WG21!):
>
> #ifdef __cplusplus
> extern "C" {
> #endif
>
> #include <stdatomic.h>
> void foo(_Atomic(int) *x);
>
> #ifdef __cplusplus
> }
> #endif
>
> https://godbolt.org/z/7osbEKrWe
>
>
>
>
> With respect to ABI, there is still the issue that _Atomic(T) types
> are not compatible between implementations even within C++:
>
> https://godbolt.org/z/EhEr3x7eh
>
>
> This could potentially be addressef by making stricter requirements
> on the representation of _Atomic(T). But as I understand it,
> implementations want to exploit the freedom to change the type
> for optimal performance and/or to insert locks into the object
> and would object to such requirements. So from the language
> side there is nothing which can be done, and the ABI issues need
> to be worked out by the implementors and ABI groups.
>
> So as I see it, there is no fundamental C/C++ compatibility
> issue here.
>
>
>
> Finally, there is the _Atomic qualifier in C which is currently
> a different way to specifiy the same type as _Atomic(T).
> From the C side, this is problematic as it is at the same
> time completely useless because it provides no new functionality
> and confusing as it does not work in he same way as any
> other qualifier.
>
>
> But the _Atomic qualifier in C also has no impact on C/C++
> compatibility at all as it is not supported in C++ (similar
> to how std::atomic<T> template syntax is not a compatibility
> problem as this is not supported in C).
>
> If WG14 were to retarget it, deprecate it, or replace it with
> something else to address the _Atomic_ref use case, this
> should not cause any problems to C++. Agreed?
>
>
> Martin
>
>
>
> [1] http://open-std.org/JTC1/SC22/WG21/docs/papers/2021/n4885.pdf
> [2] http://www.open-std.org/jtc1/sc22/wg14/www/docs/n2741.htm
>
>
>
> _______________________________________________
> 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/06/0617.php