RE: C11 atomics adoption blocked

["Morten Brørup" <mb@smartsharesystems.com>]

> From: Tyler Retzlaff [mailto:roretzla@linux.microsoft.com]
> Sent: Wednesday, 16 August 2023 19.26
> 
> On Mon, Aug 14, 2023 at 05:13:04PM +0200, Morten Brørup wrote:
> > > From: Thomas Monjalon [mailto:thomas@monjalon.net]
> > > Sent: Monday, 14 August 2023 15.46
> > >
> > > mercredi 9 août 2023, Morten Brørup:
> > > > > From: Tyler Retzlaff [mailto:roretzla@linux.microsoft.com]
> > > > > Sent: Tuesday, 8 August 2023 22.50
> > > > >
> > > > > On Tue, Aug 08, 2023 at 10:22:09PM +0200, Morten Brørup wrote:

[...]

> > > > And what about C++ atomics... Do we want (or need?) a third
> variant
> > > using C++ atomics, e.g. "atomic<int> x;" instead of "_Atomic int
> x;"? (I
> > > hope not!) For reference, the "atomic_int" type is "_Atomic int" in
> C,
> > > but "std::atomic<int>" in C++.
> > > >
> > > > C++23 provides the C11 compatibility macro "_Atomic(T)", which
> means
> > > "_Atomic T" in C and "std::atomic<T>" in C++. Perhaps we can
> somewhat
> > > rely on this, and update our coding standards to require using e.g.
> > > "_Atomic(int)" for atomic types, and disallow using "_Atomic int".
> > >
> > > You mean the syntax _Atomic(T) is working well in both C and C++?
> >
> > This syntax is API compatible across C11 and C++23, so it would work
> with (C11 and C++23) applications building DPDK from scratch.
> >
> > But it is only "recommended" ABI compatible for compilers [1], so DPDK
> in distros cannot rely on.
> >
> > [1]: https://www.open-
> std.org/jtc1/sc22/wg21/docs/papers/2020/p0943r6.html
> >
> > It would be future-proofing for the benefit of C++23 based
> applications... I was mainly mentioning it for completeness, now that we
> are switching to a new standard for atomics.
> >
> > Realistically, considering that 1. such a coding standard (requiring
> "_Atomic(T)" instead of "_Atomic T") would only be relevant for a 2023
> standard, and 2. that we are now upgrading to a standard from 2011, we
> would probably have to wait for a very distant future (12 years?) before
> C++ applications can reap the benefits of such a coding standard.
> >

Since writing the paragraph above a few day ago, I have become wiser today [1]... It turns out that the "_Atomic(T)" syntax not only comes really into play with C++23, but it is directly relevant for C11. Everyone, please pardon the confusion the above paragraph might have caused!

[1]: http://inbox.dpdk.org/dev/98CBD80474FA8B44BF855DF32C47DC35D87B0F@smartserver.smartshare.dk/

> 
> i just want to feedback on this coding convention topic here (in
> relation to the RFC patch series thread) i think the convention of using
> the macro should be adopted now. the main reason being that it is far
> easier that an atomic type is a type or a pointer type when the '*' is
> captured as a part of the macro parameter.
> 
> please see the RFC patch thread for the details of how this was
> beneficial for rcs_mcslock.h and how the placement of the _Atomic
> keyword matters when applied to pointer types of incomplete types.