Messages in this thread | | | Date | Tue, 10 Dec 2013 10:49:20 -0800 | From | "Paul E. McKenney" <> | Subject | Re: [PATCH v5 tip/core/locking 5/7] Documentation/memory-barriers.txt: Downgrade UNLOCK+LOCK |
| |
On Tue, Dec 10, 2013 at 06:43:45PM +0100, Peter Zijlstra wrote: > On Tue, Dec 10, 2013 at 09:12:47AM -0800, Paul E. McKenney wrote: > > Good point -- the UNLOCK and LOCK are guaranteed to be ordered only > > if they both operate on the same lock variable. OK, I will make the > > example use different lock variables and show the different outcomes. > > How about the following? > > > > If it is necessary for an UNLOCK-LOCK pair to > > produce a full barrier, the LOCK can be followed by an > > smp_mb__after_unlock_lock() invocation. This will produce a > > full barrier if either (a) the UNLOCK and the LOCK are executed > > by the same CPU or task, or (b) the UNLOCK and LOCK act on the > > same lock variable. > > So you're still requiring smp_mb__after_unlock_lock() even if they're on > the same variable?
Yep!
> > The smp_mb__after_unlock_lock() primitive is > > free on many architectures. Without smp_mb__after_unlock_lock(), > > the UNLOCK and LOCK can cross: > > Contradicted below :-)
Good eyes! I changed this to:
The smp_mb__after_unlock_lock() primitive is free on many architectures. Without smp_mb__after_unlock_lock(), the critical sections corresponding to the UNLOCK and the LOCK can cross:
Is that better?
> > *A = a; > > UNLOCK M > > LOCK N > > *B = b; > > > > could occur as: > > > > LOCK N, STORE *B, STORE *A, UNLOCK M > > > > With smp_mb__after_unlock_lock(), they cannot, so that: > > > > *A = a; > > UNLOCK M > > LOCK N > > smp_mb__after_unlock_lock(); > > *B = b; > > > > will always occur as either of the following: > > > > STORE *A, UNLOCK, LOCK, STORE *B > > STORE *A, LOCK, UNLOCK, STORE *B > > See, UNLOCK and LOCK can still cross :-)
Indeed they can! ;-)
> > If the UNLOCK and LOCK were instead both operating on the same > > lock variable, only the first of these two alternatives can occur. > > Agreed. > > Sorry for being a pedant. :-)
;-) ;-) ;-)
Thanx, Paul
| |