On Wed, Mar 16, 2022 at 11:09:12PM +0100, Alexander Bluhm wrote: > On Tue, Mar 15, 2022 at 09:15:34AM +0000, Visa Hankala wrote: > > However, some DEC Alpha CPUs have their data caches divided into cache > > banks to improve bandwidth. These cache banks are relatively > > independent. The system maintains coherency, but bus contention can > > delay propagation of cache updates. If the loads spanned different cache > > banks, the second load could deliver data which is older than the > > initial load's value. The data dependency barrier causes an interlock > > with cache updating, ensuring causal ordering.) > > The code with the membar is copied from READ_ONCE() which is copied > from Linux. The membar_datadep_consumer() has an #ifdef __alpha__ > in it. It is only used for that case. I don't know whether we > want to support such CPU. But if that is the case, we need the > membar.
Whether the membar is necessary or not depends on the use case. READ_ONCE(), and SMR_PTR_GET(), have it built in so that loaded pointers would work in the expected way in lockless contexts. This is intentional, the membar has not been just copied there. If you want to keep the memory barrier, then I suggest that the current atomic_load_* and atomic_store_* functions are replaced with NetBSD's atomic_load_relaxed(), atomic_load_consume(), atomic_load_acquire(), atomic_store_relaxed() and atomic_store_release(). With these, it is clear what ordering the operations provide and the programmer is able to make the appropriate choice. > What do you need refcnt_read() for? Is it only for assert? Then > a refcnt_assert() without membar or atomic_load might be better. I want to keep the API small. Even though refcnt_read() is possibly dubious in general, it allows a degree of freedom that might be useful for example in assertions. The membar question will arise in many places, not just with refcnt.
