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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Fri, 08 Nov 2013 22:05:30 -0500
From:	Waiman Long <waiman.long@...com>
To:	paulmck@...ux.vnet.ibm.com
CC:	Thomas Gleixner <tglx@...utronix.de>,
	Ingo Molnar <mingo@...hat.com>,
	"H. Peter Anvin" <hpa@...or.com>, Arnd Bergmann <arnd@...db.de>,
	linux-arch@...r.kernel.org, x86@...nel.org,
	linux-kernel@...r.kernel.org,
	Peter Zijlstra <peterz@...radead.org>,
	Steven Rostedt <rostedt@...dmis.org>,
	Andrew Morton <akpm@...ux-foundation.org>,
	Michel Lespinasse <walken@...gle.com>,
	Andi Kleen <andi@...stfloor.org>,
	Rik van Riel <riel@...hat.com>,
	Linus Torvalds <torvalds@...ux-foundation.org>,
	Raghavendra K T <raghavendra.kt@...ux.vnet.ibm.com>,
	George Spelvin <linux@...izon.com>,
	Tim Chen <tim.c.chen@...ux.intel.com>, aswin@...com,
	Scott J Norton <scott.norton@...com>
Subject: Re: [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
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/