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 Original line 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

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

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

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

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

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

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

The smp_mb__after_unlock_lock() primitive is free on many architectures.

the same variable.  The smp_mb__after_unlock_lock() primitive is free

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

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

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

execution of the critical sections corresponding to the RELEASE and the

ACQUIRE can cross, so that:





	*A = a;

	*A = a;

	RELEASE M

	RELEASE M