documentation: Fix memory-barriers.txt section references

This commit fixes a couple of "Compiler Barrier" section references to
be "COMPILER BARRIER".  This makes it easier to find the section in
the usual text editors.

Signed-off-by: Paul E. McKenney <paulmck@linux.vnet.ibm.com>
This commit is contained in:
Paul E. McKenney 2016-01-06 14:23:03 -08:00
parent 7817b799ed
commit 895f554222
1 changed files with 2 additions and 2 deletions

View File

@ -232,7 +232,7 @@ And there are a number of things that _must_ or _must_not_ be assumed:
with memory references that are not protected by READ_ONCE() and with memory references that are not protected by READ_ONCE() and
WRITE_ONCE(). Without them, the compiler is within its rights to WRITE_ONCE(). Without them, the compiler is within its rights to
do all sorts of "creative" transformations, which are covered in do all sorts of "creative" transformations, which are covered in
the Compiler Barrier section. the COMPILER BARRIER section.
(*) It _must_not_ be assumed that independent loads and stores will be issued (*) It _must_not_ be assumed that independent loads and stores will be issued
in the order given. This means that for: in the order given. This means that for:
@ -818,7 +818,7 @@ In summary:
(*) Control dependencies require that the compiler avoid reordering the (*) Control dependencies require that the compiler avoid reordering the
dependency into nonexistence. Careful use of READ_ONCE() or dependency into nonexistence. Careful use of READ_ONCE() or
atomic{,64}_read() can help to preserve your control dependency. atomic{,64}_read() can help to preserve your control dependency.
Please see the Compiler Barrier section for more information. Please see the COMPILER BARRIER section for more information.
(*) Control dependencies pair normally with other types of barriers. (*) Control dependencies pair normally with other types of barriers.