Messages in this thread | | | Date | Fri, 7 Sep 2018 17:09:50 +0100 | From | Will Deacon <> | Subject | Re: [PATCH RFC LKMM 1/7] tools/memory-model: Add extra ordering for locks and remove it for ordinary release/acquire |
| |
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
| |