Hi Alan, On Thu, Jul 12, 2018 at 01:04:27PM -0400, Alan Stern wrote: > On Thu, 12 Jul 2018, Peter Zijlstra wrote: > > But as you (and Will) point out, we don't so much care about rmw-acquire > > semantics as much as that we care about unlock+lock behaviour. Another > > way to look at this is to define: > > > > smp-store-release + rmw-acquire := TSO (ideally smp_mb) > > > > But then we also have to look at: > > > > rmw-release + smp-load-acquire > > rmw-release + rmw-acquire > > Let's assume that rmw-release is equivalent, in terms of ordering > strength, to smp_store_release(). Then we can focus our attention on > just the acquire part.
I can live with that, but it does add another special case, where we could otherwise just special case acquire/release for the load/store variants vs everything else. > On PowerPC, for instance, if spin_lock() used a full HWSYNC fence > then unlock+lock would become RCsc -- even with no changes to > spin_unlock(). > > > for completeness sake, and I would suggest they result in (at least) the > > same (TSO) ordering as the one we really care about. > > > > One alternative is to no longer use smp_store_release() for unlock(), > > and say define atomic_set_release() to be in the rmw-release class > > instead of being a simple smp_store_release(). > > > > Another, and I like this proposal least, is to introduce a new barrier > > to make this all work. > > This apparently boils down to two questions: > > Should spin_lock/spin_unlock be RCsc? I would love that to be the case, but I'm not asking you to fight that battle :) > Should rmw-acquire be strong enough so that smp_store_release + > rmw-acquire is RCtso? > > If both answers are No, we end up with the v3 patch. If the first > answer is No and the second is Yes, we end up with the v2 patch. The > problem is that different people seem to want differing answers. Just to be extra unhelpful: I'm happy with either v2 or v3. I suspect Daniel is the one to convince on v2, because it's RISC-V that's affected by this. Will