Re: [PATCH] memorder: Refine technical prose for clarity and precision

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
>