On 11/08/2013 06:51 PM, Paul E. McKenney wrote:
On Fri, Nov 08, 2013 at 05:36:12PM -0500, Waiman Long wrote:
I have some incorrect assumptions about memory barrier. Anyway, this
issue will be gone once I use the MCS lock/unlock code.
Here is a presentation that has some diagrams that might help:
http://www.rdrop.com/users/paulmck/scalability/paper/Scaling.2013.10.25c.pdf
So, for example, if X and Y are both initially zero:
CPU 0 CPU 1
ACCESS_ONCE(X) = 1; r1 = ACCESS_ONCE(Y);
smp_wmb(); smp_rmb();
ACCESS_ONCE(Y) = 1; r2 = ACCESS_ONCE(X);
Then the two memory barriers enforce a conditional ordering. The
condition is whether or not CPU 0's store to Y is seen by CPU 1's
load from Y. If it is, then the pair of memory barriers ensure that
CPU 1's load from X sees the result of CPU 0's store to X. In other
words, BUG_ON(r1 == 1&& r2 == 0) will never fire.
In general, if a memory access after memory barrier A happens before
a memory access before memory barrier B, then the two memory barriers
will ensure that applicable accesses before memory barrier A happen
before applicable accesses after memory barrier B.
Does that help?
Thanx, Paul
Thank for the pointer. I understand the purpose of the memory barrier. I
just thought that memory barrier can also kind of flush the cached data
to the memory faster. Apparently that is not the case. Anyway, I now
have a better understanding of what kind of barriers are needed in
locking primitives by observing conversation in this and related threads.
-Longman
--
To unsubscribe from this list: send the line "unsubscribe linux-arch" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
