lkml.org 
[lkml]   [2013]   [Dec]   [10]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [PATCH tip/core/locking 4/4] Documentation/memory-barriers.txt: Document ACCESS_ONCE()

* Paul E. McKenney <paulmck@linux.vnet.ibm.com> wrote:

> > [...]
> >
> > > + (*) The compiler is within its rights to reorder memory accesses unless
> > > + you tell it not to. For example, consider the following interaction
> > > + between process-level code and an interrupt handler:
> > > +
> > > + void process_level(void)
> > > + {
> > > + msg = get_message();
> > > + flag = true;
> > > + }
> > > +
> > > + void interrupt_handler(void)
> > > + {
> > > + if (flag)
> > > + process_message(msg);
> > > + }
> > > +
> > > + There is nothing to prevent the the compiler from transforming
> > > + process_level() to the following, in fact, this might well be a
> > > + win for single-threaded code:
> > > +
> > > + void process_level(void)
> > > + {
> > > + flag = true;
> > > + msg = get_message();
> > > + }
> > > +
> > > + If the interrupt occurs between these two statement, then
> > > + interrupt_handler() might be passed a garbled msg. Use ACCESS_ONCE()
> > > + to prevent this as follows:
> > > +
> > > + void process_level(void)
> > > + {
> > > + ACCESS_ONCE(msg) = get_message();
> > > + ACCESS_ONCE(flag) = true;
> > > + }
> > > +
> > > + void interrupt_handler(void)
> > > + {
> > > + if (ACCESS_ONCE(flag))
> > > + process_message(ACCESS_ONCE(msg));
> > > + }
> >
> > Looking at this, I find myself wondering why you couldn't just put a
> > barrier() between the two statements in process_level()? ACCESS_ONCE()
> > seems like a heavy hammer to just avoid reordering of two assignments.
> > What am I missing, and what could be added here to keep the other folks as
> > dense as me from missing the same thing?
>
> You could use barrier() from an ordering viewpoint. However,
> ACCESS_ONCE() is often lighter weight than barrier(). ACCESS_ONCE()
> affects only that one access, while barrier() forces the compiler to
> forget pretty much anything it previously gleaned from any region of
> memory, including private locations that no one else touches.
>
> I am adding a sentence saying that pure ordering can be provided by
> barrier(), though often at higher cost.

I suspect a related question would be, is the compiler allowed to
reorder:


x = ACCESS_ONCE(a);
y = ACCESS_ONCE(b);

?

This wording:

+ [...] Howevever, ACCESS_ONCE() can be thought of as a weak form
+for barrier() that affects only the specific accesses flagged by the
+ACCESS_ONCE().

Does not seem to be obvious enough to me - does it affect accesses to
the variables referenced (but still allows accesses to separate
variables reordered), or does it affect compiler-ordering of all
ACCESS_ONCE() instances, instructing the compiler to preserve program
order?

Also, it's not clear what happens if non-ACCESS_ONCE() access to a
variable is mixed with ACCESS_ONCE() access.

Thanks,

Ingo


\
 
 \ /
  Last update: 2013-12-10 16:41    [W:0.113 / U:0.108 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site