Re: rte_atomic_*_explicit

[Tyler Retzlaff <roretzla@linux.microsoft.com>]

On Fri, Jan 26, 2024 at 04:58:54PM +0000, Honnappa Nagarahalli wrote:
> <snip>
> 
> > >
> > >>
> > >> On Thu, Jan 25, 2024 at 11:10:47PM +0100, Morten Br�rup wrote:
> > >>>> From: Mattias R�nnblom [mailto:hofors@lysator.liu.se]
> > >>>> Sent: Thursday, 25 January 2024 19.54
> > >>>>
> > >>>> Why do rte_stdatomic.h functions have the suffix "_explicit"?
> > >>>> Especially
> > >>>> since there aren't any wrappers for the implicit variants.
> > >>>>
> > >>>> More to type, more to read.
> > >>>
> > >>> They have the "_explicit" suffix to make their names similar to
> > >>> those in
> > >> stdatomic.h.
> > >>>
> > >>> You might consider their existence somewhat temporary until C11
> > >>> stdatomics
> > >> can be fully phased in, so there's another argument for similar
> > >> names. (This probably does not happen as long as compilers generate
> > >> slower code for C11 stdatomics than with their atomic built-ins.)
> > >>
> > >> yes, there was feedback at the time it was.
> > >>
> > >> * we should *not* have non-explicit versions of the macros
> > >> * the atomic generic functions should be named to match C11 standard
> > >>    with a rte_ prefix.
> > > This was mainly done to ensure that users think through the memory
> > ordering they want to use. This also matches with the compiler atomic built-
> > ins. Without explicit, it is sequentially consistent memory order.
> > >
> > 
> > "This" is referring to the first bullet only, correct?
> > 
> > You don't have to distinguish between implicit and explicit if you only have
> > explicit.
> Agree on your thought.
> 
> The '_explicit' was added to be aligned with the standard atomic API naming. The thought was - if we are aligned on the names, it needs less explanation for users.

well another benefit is that in the future if/when a decision is made to
directly use the names from the standard it is most trivial to just
strip the rte_ prefix tree wide.