[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <Pine.LNX.4.44L0.1710181716590.1528-100000@iolanthe.rowland.org>
Date: Wed, 18 Oct 2017 17:18:37 -0400 (EDT)
From: Alan Stern <stern@...land.harvard.edu>
To: "Paul E. McKenney" <paulmck@...ux.vnet.ibm.com>
cc: Andrea Parri <parri.andrea@...il.com>,
Will Deacon <will.deacon@....com>, <peterz@...radead.org>,
<boqun.feng@...il.com>, <npiggin@...il.com>, <dhowells@...hat.com>,
Jade Alglave <j.alglave@....ac.uk>,
Luc Maranget <luc.maranget@...ia.fr>,
Kernel development list <linux-kernel@...r.kernel.org>
Subject: Re: Linux-kernel examples for LKMM recipes
On Wed, 18 Oct 2017, Paul E. McKenney wrote:
> > Well, you could explicitly mention that in the multi-thread case, this
> > means all accesses to the shared variable had better use READ_ONCE() or
> > WRITE_ONCE().
>
> Like this?
>
> Thanx, Paul
>
> ------------------------------------------------------------------------
>
> d. If there are multiple CPUs, accesses to shared variables
> should use READ_ONCE() and WRITE_ONCE() or stronger
> to prevent load/store tearing, load/store fusing, and
> invented loads and stores. There are exceptions to
> this rule, for example:
>
> i. When there is no possibility of a given
> shared variable being updated, for example,
> while holding the update-side lock, reads
> from that variable need not use READ_ONCE().
>
> ii. When there is no possibility of a given shared
> variable being either read or updated, for
> example, when running during early boot, reads
> from that variable need not use READ_ONCE() and
> writes to that variable need not use WRITE_ONCE().
Yeah, except that you mean being read or updated by another thread.
Alan
Powered by blists - more mailing lists