buf_ring: Consistently use atomic_*_32

[andrew]

Summary

We are operating on uint32_t values, use uint32_t atomic functions.

Sponsored by: Arm Ltd

[imp]

A question about volatile away from the review.
Having both atomics and volatile isn't the usual pattern and the CW has usually been that adding volatile won't fix code like this, so either remove volatile, or comment about what it accomplishes likely is appropriate even if it's a brief reference....

sys/sys/buf_ring.h

49

So do these need to be volatile since we're using atomics on them?
And how does forcing a fetch actually ensure that another thread's modification is visible to the current execution unit, or does that race somehow not matter?
I'd think the answers to these questions should be, at least in brief form, commented somewhere. It's always hard to reason, exactly, about this stuff and knowing why each layer is needed would be helpful for people that aren't in the minutia of atomics every day enough to know this level of nuance off the top of their heads.

[kib]

sys/sys/buf_ring.h

49

Iif all accesses are consistently use atomic_ primitives, there is no sense in having volatile CV modifiers.

The question of visibility is much more nuanced, and typically when using acq/rel pattern, we explain which acq pair with which rel, and what data modifications should be visible to acq consumer when rel store was noticed.

[andrew]

sys/sys/buf_ring.h

49

There are still a few places we use the values directly and not through an atomic function. We could move all accesses of the head and tail values to use atomic(9) and remove volatile from here in a follow up.

[markj]

sys/sys/buf_ring.h

49

+1 for removing the volatile annotation.