RE: rte_atomic_*_explicit

[Honnappa Nagarahalli <Honnappa.Nagarahalli@arm.com>]

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

> 
> >>
> >>>
> >>>>
> >>>> When was this API introduced? Shouldn't it say "experimental"
> >>>> somewhere?
> >>>
> >>> They were introduced as part of the migration to C11.
> >>> I suppose they were not marked experimental because they replaced
> >> something we didn't want anymore (the compiler built-ins for atomics, e.g.
> >> __atomic_load_n()). I don't recall if we discussed experimental marking or
> not.
> >>
> >> i don't think we discussed it since they're wrapper macros.
> >>
> >>>
> >>>
> >>> Reverse paper trail:
> >>> https://git.dpdk.org/dpdk/log/lib/eal/include/rte_stdatomic.h
> >>> https://patchwork.dpdk.org/project/dpdk/patch/1692738045-32363-2-git
> >>> -
> >> send-email-roretzla@linux.microsoft.com/
> >>> https://patchwork.dpdk.org/project/dpdk/patch/1692738045-32363-2-git
> >>> -
> >> send-email-roretzla@linux.microsoft.com/
> >>>