doc: Rewrite confusing statement about memory barriers
authorGuilherme G. Piccoli <gpiccoli@linux.vnet.ibm.com>
Thu, 21 Sep 2017 19:29:01 +0000 (16:29 -0300)
committerPaul E. McKenney <paulmck@linux.vnet.ibm.com>
Fri, 20 Oct 2017 18:09:32 +0000 (11:09 -0700)
The "Write (or store) memory barriers" bullet of the "Variety of memory
barriers" section, calls out a sequential order of stores, which is
confusing since sequential ordering is not guaranteed.

This commit therefore rewords to avoid mentioning a sequence of stores
to clarify the intent.

Cc: Paul E. McKenney <paulmck@linux.vnet.ibm.com>
Signed-off-by: Guilherme G. Piccoli <gpiccoli@linux.vnet.ibm.com>
Signed-off-by: Paul E. McKenney <paulmck@linux.vnet.ibm.com>
Documentation/memory-barriers.txt

index f373755..519940e 100644 (file)
@@ -383,8 +383,8 @@ Memory barriers come in four basic varieties:
      to have any effect on loads.
 
      A CPU can be viewed as committing a sequence of store operations to the
-     memory system as time progresses.  All stores before a write barrier will
-     occur in the sequence _before_ all the stores after the write barrier.
+     memory system as time progresses.  All stores _before_ a write barrier
+     will occur _before_ all the stores after the write barrier.
 
      [!] Note that write barriers should normally be paired with read or data
      dependency barriers; see the "SMP barrier pairing" subsection.