Re: [PATCH v5 1/4] qrwlock: A queue read/write lock implementation

[Waiman Long]

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-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/