On Fri, Sep 07, 2018 at 12:00:19PM -0400, Alan Stern wrote: > On Thu, 6 Sep 2018, Andrea Parri wrote: > > > > Have you noticed any part of the generic code that relies on ordinary > > > acquire-release (rather than atomic RMW acquire-release) in order to > > > implement locking constructs? > > > > There are several places in code where the "lock-acquire" seems to be > > provided by an atomic_cond_read_acquire/smp_cond_load_acquire: I have > > mentioned one in qspinlock in this thread; qrwlock and mcs_spinlock > > provide other examples (grep for the primitives...). > > > > As long as we don't consider these primitive as RMW (which would seem > > odd...) or as acquire for which "most people expect strong ordering" > > (see above), these provides other examples for the _gap_ I mentioned. > > Okay, now I understand your objection. It does appear that on RISC-V, > if nowhere else, the current implementations of qspinlock, qrwlock, > etc. will not provide "RCtso" ordering. > > The discussions surrounding this topic have been so lengthy and > confusing that I have lost track of any comments Palmer or Daniel may > have made concerning this potential problem. > > One possible resolution would be to define smp_cond_load_acquire() > specially on RISC-V so that it provided the same ordering guarantees as > RMW-acquire. (Plus adding a comment in the asm-generic/barrier.h > pointing out the necessity for the stronger guarantee on all > architectures.) > > Another would be to replace the usages of atomic/smp_cond_load_acquire > in the locking constructs with a new function that would otherwise be > the same but would provide the ordering guarantee we want. > > Do you think either of these would be an adequate fix? I didn't think RISC-V used qspinlock or qrwlock, so I'm not sure there's actually anything to fix, is there? Will
