Donate to e Foundation | Murena handsets with /e/OS | Own a part of Murena! Learn more

Commit 96d7744e authored by Paul E. McKenney's avatar Paul E. McKenney
Browse files

doc: Call out smp_mb__after_unlock_lock() transitivity 



Although "full barrier" should be interpreted as providing transitivity,
it is worth eliminating any possible confusion.  This commit therefore
adds "(including transitivity)" to eliminate any possible confusion.

Reported-by: default avatarPeter Zijlstra <peterz@infradead.org>
Signed-off-by: default avatarPaul E. McKenney <paulmck@linux.vnet.ibm.com>
parent 9af194ce

Documentation/memory-barriers.txt

+6 −5
Original line number Diff line number Diff line
@@ -1858,11 +1858,12 @@ Similarly, the reverse case of a RELEASE followed by an ACQUIRE does not 
imply a full memory barrier.  If it is necessary for a RELEASE-ACQUIRE

pair to produce a full barrier, the ACQUIRE can be followed by an

smp_mb__after_unlock_lock() invocation.  This will produce a full barrier

if either (a) the RELEASE and the ACQUIRE are executed by the same

CPU or task, or (b) the RELEASE and ACQUIRE act on the same variable.

The smp_mb__after_unlock_lock() primitive is free on many architectures.

Without smp_mb__after_unlock_lock(), the CPU's execution of the critical

sections corresponding to the RELEASE and the ACQUIRE can cross, so that:

(including transitivity) if either (a) the RELEASE and the ACQUIRE are

executed by the same CPU or task, or (b) the RELEASE and ACQUIRE act on

the same variable.  The smp_mb__after_unlock_lock() primitive is free

on many architectures.  Without smp_mb__after_unlock_lock(), the CPU's

execution of the critical sections corresponding to the RELEASE and the

ACQUIRE can cross, so that:



	*A = a;

	RELEASE M