Re: Is WRITE_ONCE() enough to prevent invention of stores?

["Paul E. McKenney" <paulmck@linux.vnet.ibm.com>]

On Wed, Nov 01, 2017 at 12:36:13AM +0900, Akira Yokosawa wrote:
> On 2017/10/30 11:14:23 -0700, Paul E. McKenney wrote:
> > On Mon, Sep 18, 2017 at 07:51:29AM +0900, Akira Yokosawa wrote:
> >> On 2017/09/17 14:55:08 -0700, Paul E. McKenney wrote:
> >>> On Sun, Sep 17, 2017 at 08:04:21PM +0900, Akira Yokosawa wrote:
> >>>> On 2017/09/16 18:07:30 -0700, Paul E. McKenney wrote:
> >>>>> On Sat, Sep 16, 2017 at 08:01:45PM +0900, Akira Yokosawa wrote:

[ . . . ]

> >>>> Adding this example in the text might be too verbose.
> >>>> Would a Quick Quiz be reasonable?
> >>>
> >>> Might be good in the section on protecting memory references, and putting
> >>> it into a quick quiz or two makes a lot of sense.
> >>
> >> It's up to you where to put it.
> >>
> >> And I now realize using READ_ONCE() and WRITE_ONCE() is quite tricky.
> >> Missing one might not cause a problem today, but a smarter compiler
> >> can expose the bug in the future...
> >>
> >> This is scary.
> > 
> > Section 15.3.1 is supposed to cover READ_ONCE() and WRITE_ONCE().
> > There is one final paragraph added just now, but if you get a chance,
> > please let me know what you think.
> 
> It looks OK to me. Some minor nitpicks.
> 
> * On exact exceptions and exact interrupts:
> 
> IIRC, I've heard from you that there is an exceptional architecture
> which requires explicit memory barriers in exception/interrupt handlers.
> Was it Itanium?

For interrupts from kernel code, it is sometimes the case that the
kernel needs other CPUs to see the accesses in the code before the
interrupt handler, the code within the interrupt handler, and the code
after the interrupt handler to have happened in order.  In that case,
the interrupt entry/exit code might well need full memory barriers.

There are other ways to organize this that do not require interrupt
entry/exit memory barriers, for example, the convention could be that
locking be used.

> * On the final paragraph of Section 15.3.1:
> 
> "Nevertheless" appears twice in this paragraph. You might want to
> reword one of them.

Good point, how about the following?

	Nevertheless, it is quite possible to overdo use of READ_ONCE()
	and WRITE_ONCE(). For example, if you have prevented a given
	variable from changing (perhaps by holding the lock guarding
	all updates to that variable), there is no point in using
	READ_ONCE(). Similarly, if you have prevented any other CPUs or
	threads from reading a given variable (perhaps because you are
	initializing that variable before any other CPU or thread has
	access to it), there is no point in using WRITE_ONCE(). However,
	my experience is that developers need to use things like
	READ_ONCE() and WRITE_ONCE() more often than they think that
	they do, the overhead of unnecessary uses is quite low, and the
	penalty for failing to use them when needed is quite high.

							Thanx, Paul

> > And if you are scared, you might actually have a good understanding
> > of the true situation.  ;-)
> 
> Whew!!!
> 
>      Thanks, Akira
> 
> > 
> > 							Thanx, Paul
> > 
> >>          Thanks, Akira
> >>
> >>>
> >>> 							Thanx, Paul
> >>>
> >>>>         Thanks, Akira
> >>>>
> >>>>>
> >>>>> 							Thanx, Paul
> >>>>>
> >>>>>
> >>>>
> >>>
> >>>
> >>
> > 
> > 
>