On 2024-05-02 20:26, Stephen Hemminger wrote:
On Thu, 2 May 2024 19:37:28 +0200
Mattias Rönnblom <hof...@lysator.liu.se> wrote:
Do we need to declare count as '_Atomic', I wasn't planning to make
variable _Atomic. This way assignment won't introduce any memory barrier.
To use atomics in DPDK, the current requirements seems to be to use
RTE_ATOMIC(). That macro expands to _Atomic in enable_stdatomic=true
builds, and nothing otherwise.
Carefully crafted code using atomics will achieved the same performance
and be more correct than the non-atomic variant. However, in practice, I
think the non-atomic variant is very likely to produce the desired results.
You are confusing atomic usage for thread safety, with the necessity
of compiler barriers.
Are you suggesting that program-level C11 atomic stores risk being
delayed, indefinitely? I could only find a draft version of the
standard, but there 7.17.3 says "Implementations should make atomic
stores visible to atomic loads within a reasonable amount of time."
An atomic relaxed store will be much cheaper than a compiler barrier.
Stats should not be volatile.
Sure, and I also don't think compiler barriers should be needed.
