rte_atomic_*_explicit

[Mattias Rönnblom]

On 2024-01-26 02:37, Honnappa Nagarahalli wrote:
> <snip>
> 
>>
>> On Thu, Jan 25, 2024 at 11:10:47PM +0100, Morten Br�rup wrote:
>>>> From: Mattias R�nnblom [mailto:hofors at 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.

>>
>>>
>>>>
>>>> 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 at linux.microsoft.com/
>>> https://patchwork.dpdk.org/project/dpdk/patch/1692738045-32363-2-git-
>> send-email-roretzla at linux.microsoft.com/
>>>