lkml.org 
[lkml]   [2013]   [Nov]   [8]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [PATCH v5 1/4] qrwlock: A queue read/write lock implementation
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


\
 
 \ /
  Last update: 2013-11-09 04:21    [W:0.045 / U:0.304 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site