On Fri, Mar 06, 2026 at 04:29:22PM +0800, Kunwu Chan wrote:
> Polish typography and grammar in memory-ordering text to improve
> precision, readability, and editorial consistency while preserving
> technical semantics.
>
> Signed-off-by: Kunwu Chan <[email protected]>
Again, good eyes! Queued and pushed, thank you very much!!!
Thanx, Paul
> ---
> memorder/memorder.tex | 20 ++++++++++----------
> 1 file changed, 10 insertions(+), 10 deletions(-)
>
> diff --git a/memorder/memorder.tex b/memorder/memorder.tex
> index d1ebb93c..16a569d1 100644
> --- a/memorder/memorder.tex
> +++ b/memorder/memorder.tex
> @@ -15,7 +15,7 @@ These intuitions can be quite helpful when writing,
> analyzing, and
> debugging not only sequential code, but also parallel code that makes
> use of standard mutual-exclusion mechanisms such as locking.
> Unfortunately, these intuitions break down completely in complex
> -concurrent code, such as that in the Linux-kernel, which often uses
> +concurrent code, such as that in the Linux-kernel, which often uses
> weakly ordered atomic operations and memory barriers.
> One example of such code implements the standard mutual-exclusion
> mechanisms themselves, while another example implements fast
> @@ -316,8 +316,8 @@ stored by a release, discussed in
> then the code following that release will see all accesses preceding
> the acquire.
> More precisely, if CPU~0 does an acquire that loads the value stored by
> -CPU~1's release, than all the subsequent accesses executed by CPU~0 will
> -see the all of CPU~1's accesses prior to its release.
> +CPU~1's release, then all the subsequent accesses executed by CPU~0 will
> +see all of CPU~1's accesses prior to its release.
>
> Similarly, the accesses preceding that release access will be protected
> from seeing the accesses following the acquire access.
> @@ -561,7 +561,7 @@ on
> This counter-temporal nature of load-to-store and store-to-store
> links necessitates strong ordering.
>
> - In constrast, store-to-load links are temporal, as illustrated by
> + In contrast, store-to-load links are temporal, as illustrated by
> \cref{lst:memorder:Load-Buffering Data-Dependency Litmus Test,%
> lst:memorder:Load-Buffering Control-Dependency Litmus Test}.
> This temporal nature of store-to-load links permits use of
> @@ -882,7 +882,7 @@ record their stores in their respective store buffers.
> How can that possibly work???
> }\QuickQuizAnswer{
> There is an underlying cache-coherence protocol that straightens
> - things out, which are discussed in
> + things out, which is discussed in
> \cref{sec:app:whymb:Cache-Coherence Protocols}.
> But if you think that a given variable having two values at
> the same time is surprising, just wait until you get to
> @@ -1040,7 +1040,7 @@ Although full barriers such as \co{smp_mb()} have
> extremely strong
> ordering guarantees, their strength comes at a high price in terms
> of foregone hardware and compiler optimizations.
> A great many situations can be handled with much weaker ordering guarantees
> -that use much cheaper memory-ordering instructions, or, in some case, no
> +that use much cheaper memory-ordering instructions, or, in some cases, no
> memory-ordering instructions at all.
>
> \begin{table*}
> @@ -1184,7 +1184,7 @@ are at most two threads involved.
>
> The \co{*_dereference()} row captures the address and data
> dependency ordering provided by \co{rcu_dereference()} and friends.
> - Again, these dependencies must been constructed carefully,
> + Again, these dependencies must have been constructed carefully,
> as described in
> \cref{sec:memorder:Address- and Data-Dependency Difficulties}.
>
> @@ -2459,7 +2459,7 @@ might reach \co{P2()} before \co{P0()}'s store does.
> This leads to the question of why a real system constrained by the
> usual laws of physics would ever trigger the \co{exists} clause of
> \cref{lst:memorder:WRC Litmus Test With Dependencies (No Ordering)}.
> -The cartoonish diagram of a such a real system is shown in
> +The cartoonish diagram of such a real system is shown in
> \cref{fig:memorder:Shared Store Buffers And Multi-Copy Atomicity}.
> CPU~0 and CPU~1 share a store buffer, as do CPUs~2 and~3.
> This means that CPU~1 can load a value out of the store buffer, thus
> @@ -3536,8 +3536,8 @@ can be satisfied:
>
> At this point, you should see something like
> \cref{fig:memorder:PPCMEM Final R State}.
> -Note that the satisified \co{exists} clause is shown in blue near the
> -bottom, confirming that this counter-intuitive really can happen.
> +Note that the satisfied \co{exists} clause is shown in blue near the
> +bottom, confirming that this counter-intuitive result really can happen.
> If you wish, you can click on ``Undo'' to explore other options or
> click on ``Reset'' to start over.
> It can be very helpful to carry out these steps in different orders
> --
> 2.25.1
>
