Messages in this thread | | | Date | Thu, 12 Nov 2015 21:53:04 +0000 | From | Will Deacon <> | Subject | Re: [PATCH 4/4] locking: Introduce smp_cond_acquire() |
| |
On Thu, Nov 12, 2015 at 07:02:51AM -0800, Paul E. McKenney wrote: > On Thu, Nov 12, 2015 at 10:49:02PM +0800, Boqun Feng wrote: > > On Thu, Nov 12, 2015 at 06:40:04AM -0800, Paul E. McKenney wrote: > > [snip] > > > > > > I cannot resist suggesting that any lock that interacts with > > > spin_unlock_wait() must have all relevant acquisitions followed by > > > smp_mb__after_unlock_lock(). > > > > > > > But > > > > 1. This would expand the purpose of smp_mb__after_unlock_lock(), > > right? smp_mb__after_unlock_lock() is for making UNLOCK-LOCK > > pair global transitive rather than guaranteeing no operations > > can be reorder before the STORE part of LOCK/ACQUIRE. > > Indeed it would. Which might be OK. > > > 2. If ARM64 has the same problem as PPC now, > > smp_mb__after_unlock_lock() can't help, as it's a no-op on > > ARM64. > > Agreed, and that is why we need Will to weigh in.
I really don't want to implement smp_mb__after_unlock_lock, because we don't need it based on its current definition and I think there's a better way to fix spin_unlock_wait (see my other post).
Will
| |