Skip to content

Commit 81c105d

Browse files
committed
Fix inconsistency of code style
1. split setences into separate lines 2. change the quotation marks "..." as ``...''
1 parent 8432419 commit 81c105d

File tree

1 file changed

+57
-20
lines changed

1 file changed

+57
-20
lines changed

concurrency-primer.tex

Lines changed: 57 additions & 20 deletions
Original file line numberDiff line numberDiff line change
@@ -749,11 +749,17 @@ \section{Memory orderings}
749749

750750
\subsection{Memory consistency models}
751751

752-
When a program is compiled and executed, it doesn't always follow the written order. The system may change the sequence and optimize it to simulate line-by-line execution, as long as the final result matches the expected outcome.
752+
When a program is compiled and executed, it doesn't always follow the written order.
753+
The system may change the sequence and optimize it to simulate line-by-line execution, as long as the final result matches the expected outcome.
753754

754-
This requires an agreement between the programmer and the system (hardware, compiler, etc.), ensuring that if the rules are followed, the execution will be correct. Correctness here means defining permissible outcomes among all possible results, known as memory consistency models. These models allow the system to optimize while ensuring correct execution.
755+
This requires an agreement between the programmer and the system (hardware, compiler, etc.), ensuring that if the rules are followed, the execution will be correct.
756+
Correctness here means defining permissible outcomes among all possible results, known as memory consistency models.
757+
These models allow the system to optimize while ensuring correct execution.
755758

756-
Memory consistency models operate at various levels. For example, when machine code runs on hardware, processors can reorder and optimize instructions, and the results must match expectations. Similarly, when converting high-level languages to assembly, compilers can rearrange instructions while ensuring consistent outcomes. Thus, from source code to hardware execution, agreements must ensure the expected results.
759+
Memory consistency models operate at various levels.
760+
For example, when machine code runs on hardware, processors can reorder and optimize instructions, and the results must match expectations.
761+
Similarly, when converting high-level languages to assembly, compilers can rearrange instructions while ensuring consistent outcomes.
762+
Thus, from source code to hardware execution, agreements must ensure the expected results.
757763

758764
\subsubsection{Sequential consistency (SC)}
759765

@@ -763,13 +769,19 @@ \subsubsection{Sequential consistency (SC)}
763769
A multiprocessor system is sequentially consistent if the result of any execution is the same as if the operations of all the processors were executed in some sequential order, and the operations of each individual processor appear in this sequence in the order specified by its program.
764770
\end{quote}
765771

766-
On modern processors, ensuring sequential consistency involves many optimization constraints, which slow down program execution. If some conventions are relaxed, such as not guaranteeing program order within each processing unit, performance can be further improved.
772+
On modern processors, ensuring sequential consistency involves many optimization constraints, which slow down program execution.
773+
If some conventions are relaxed, such as not guaranteeing program order within each processing unit, performance can be further improved.
767774

768-
A memory consistency model is a conceptual convention. This means the program's execution results must conform to this model. However, when a program is compiled and run on computer hardware, there is significant flexibility in adjusting the execution order. As long as the execution results match the predefined convention, the actual order can vary depending on the circumstances.
775+
A memory consistency model is a conceptual convention.
776+
This means the program's execution results must conform to this model.
777+
However, when a program is compiled and run on computer hardware, there is significant flexibility in adjusting the execution order.
778+
As long as the execution results match the predefined convention, the actual order can vary depending on the circumstances.
769779

770-
It is important to note that sequential consistency does not imply a single order or a single result for the program. On the contrary, sequential consistency only requires that the program appears to execute in some interleaved order on a single thread, meaning a sequentially consistent program can still have multiple possible results.
780+
It is important to note that sequential consistency does not imply a single order or a single result for the program.
781+
On the contrary, sequential consistency only requires that the program appears to execute in some interleaved order on a single thread, meaning a sequentially consistent program can still have multiple possible results.
771782

772-
To enhance the understanding of sequential consistency, consider the following simple example. Two threads write to and read from two shared variables \monobox{x} and \monobox{y}, both initially set to \monobox{0}.
783+
To enhance the understanding of sequential consistency, consider the following simple example.
784+
Two threads write to and read from two shared variables \monobox{x} and \monobox{y}, both initially set to \monobox{0}.
773785

774786
\begin{ccode}
775787
// Litmus Test: Message Passing
@@ -781,7 +793,8 @@ \subsubsection{Sequential consistency (SC)}
781793
y = 1; r2 = x;
782794
\end{ccode}
783795

784-
If this program satisfies sequential consistency, then for Thread 1, \monobox{x = 1} must occur before \monobox{y = 1}, and for Thread 2, \monobox{r1 = y} must occur before \monobox{r2 = x}. For the entire program, the following six execution orders are possible:
796+
If this program satisfies sequential consistency, then for Thread 1, \monobox{x = 1} must occur before \monobox{y = 1}, and for Thread 2, \monobox{r1 = y} must occur before \monobox{r2 = x}.
797+
For the entire program, the following six execution orders are possible:
785798

786799
\begin{verbatim}
787800
| x = 1 | x = 1 | x = 1 |
@@ -795,19 +808,26 @@ \subsubsection{Sequential consistency (SC)}
795808
| r2 = x(1) | y = 1 | y = 1 |
796809
\end{verbatim}
797810

798-
Observing these orders, we see that none result in \monobox{r1 = 1} and \monobox{r2 = 0}. Thus, sequential consistency only allows the outcomes \monobox{(r1, r2)} to be \monobox{(1, 1)}, \monobox{(0, 1)}, and \monobox{(0, 0)}. With this convention, software can expect that \monobox{(1, 0)} will not occur, and hardware can optimize as long as it ensures the result \monobox{(1, 0)} does not appear.
811+
Observing these orders, we see that none result in \monobox{r1 = 1} and \monobox{r2 = 0}.
812+
Thus, sequential consistency only allows the outcomes \monobox{(r1, r2)} to be \monobox{(1, 1)}, \monobox{(0, 1)}, and \monobox{(0, 0)}.
813+
With this convention, software can expect that \monobox{(1, 0)} will not occur, and hardware can optimize as long as it ensures the result \monobox{(1, 0)} does not appear.
799814

800815
\begin{center}
801816
\includegraphics[keepaspectratio,width=0.7\linewidth]{images/hw-seq-cst}
802817
\captionof{figure}{The memory model of sequentially consistent hardware.}
803818
\label{hw-seq-cst}
804819
\end{center}
805820

806-
We can imagine sequentially consistent hardware as the figure \ref{hw-seq-cst} shows: each thread can directly access shared memory, and memory processes one read or write operation at a time, naturally ensuring sequential consistency. In fact, there are multiple ways to implement sequentially consistent hardware. It can even include caches and be banked, as long as it ensures that the results behave the same as the aforementioned model.
821+
We can imagine sequentially consistent hardware as the figure \ref{hw-seq-cst} shows: each thread can directly access shared memory, and memory processes one read or write operation at a time, naturally ensuring sequential consistency.
822+
In fact, there are multiple ways to implement sequentially consistent hardware.
823+
It can even include caches and be banked, as long as it ensures that the results behave the same as the aforementioned model.
807824

808825
\subsubsection{Total store order (TSO)}
809826

810-
Although sequential consistency is considered the "golden standard" for multi-threaded programs, its many constraints limit performance optimization. As a result, it is rarely implemented in modern processors. Instead, more relaxed memory models are used, such as the total store order (TSO) memory model adopted by the x86 architecture. One can envision the hardware roughly as follows:
827+
Although sequential consistency is considered the ``golden standard'' for multi-threaded programs, its many constraints limit performance optimization.
828+
As a result, it is rarely implemented in modern processors.
829+
Instead, more relaxed memory models are used, such as the total store order (TSO) memory model adopted by the x86 architecture.
830+
One can envision the hardware roughly as follows:
811831

812832
\begin{center}
813833
\includegraphics[keepaspectratio,width=0.7\linewidth]{images/hw-tso}
@@ -829,9 +849,12 @@ \subsubsection{Total store order (TSO)}
829849
r1 = y; r2 = x;
830850
\end{ccode}
831851

832-
Sequential consistency does not allow \monobox{r1 = r2 = 0}, but TSO does. In a sequentially consistent memory model, \monobox{x = 1} or \monobox{y = 1} must be written first, followed by the read operations, so \monobox{r1 = r2 = 0} cannot occur. However, under the TSO memory model, the write operations from both threads might still be in their respective queues when the read operations occur, allowing \monobox{r1 = r2 = 0}.
852+
Sequential consistency does not allow \monobox{r1 = r2 = 0}, but TSO does.
853+
In a sequentially consistent memory model, \monobox{x = 1} or \monobox{y = 1} must be written first, followed by the read operations, so \monobox{r1 = r2 = 0} cannot occur.
854+
However, under the TSO memory model, the write operations from both threads might still be in their respective queues when the read operations occur, allowing \monobox{r1 = r2 = 0}.
833855

834-
Non-sequentially consistent hardware typically supports additional memory barrier (fence) instructions to control the order of read and write operations. These barriers ensure that writes before the barrier are completed (queues emptied) before any subsequent reads are performed.
856+
Non-sequentially consistent hardware typically supports additional memory barrier (fence) instructions to control the order of read and write operations.
857+
These barriers ensure that writes before the barrier are completed (queues emptied) before any subsequent reads are performed.
835858

836859
\begin{ccode}
837860
// Thread 1 // Thread 2
@@ -840,7 +863,9 @@ \subsubsection{Total store order (TSO)}
840863
r1 = y; r2 = x;
841864
\end{ccode}
842865

843-
The reason total store order (TSO) is named as such is because once a write operation reaches shared memory, it indicates that all processors are aware that the value has been written. There will be no situation where different processors see different values. That is, the following litmus test will not have \monobox{r1 = 1}, \monobox{r2 = 0}, \monobox{r3 = 1}, but \monobox{r4 = 0}.
866+
The reason total store order (TSO) is named as such is because once a write operation reaches shared memory, it indicates that all processors are aware that the value has been written.
867+
There will be no situation where different processors see different values.
868+
That is, the following litmus test will not have \monobox{r1 = 1}, \monobox{r2 = 0}, \monobox{r3 = 1}, but \monobox{r4 = 0}.
844869

845870
Consider the following Independent Reads of Independent Writes (IRIW) Litmus Test:
846871

@@ -854,7 +879,9 @@ \subsubsection{Total store order (TSO)}
854879
r2 = y; r4 = x;
855880
\end{ccode}
856881

857-
Once Thread 3 reads \monobox{r1 = 1}, \monobox{r2 = 0}, it indicates that the write \monobox{x = 1} reached shared memory before \monobox{y = 1}. If at this point Thread 4 reads \monobox{r3 = 1}, it means both writes \monobox{y = 1} and \monobox{x = 1} are visible to Thread 4, so \monobox{r4} can only be \monobox{1}. We can say "Thread 1's write to \monobox{x}" happens before "Thread 2's write to \monobox{y}".
882+
Once Thread 3 reads \monobox{r1 = 1}, \monobox{r2 = 0}, it indicates that the write \monobox{x = 1} reached shared memory before \monobox{y = 1}.
883+
If at this point Thread 4 reads \monobox{r3 = 1}, it means both writes \monobox{y = 1} and \monobox{x = 1} are visible to Thread 4, so \monobox{r4} can only be \monobox{1}.
884+
We can say "Thread 1's write to \monobox{x}" happens before "Thread 2's write to \monobox{y}".
858885

859886
\subsubsection{Relaxed memory order (RMO)}
860887

@@ -864,11 +891,21 @@ \subsubsection{Relaxed memory order (RMO)}
864891
\label{hw-relaxed}
865892
\end{center}
866893

867-
As shown in figure \ref{hw-relaxed}, the \textsc{Arm} instruction set adopts a more relaxed memory model. Each thread maintains its own copy of the memory, and every read and write operation targets this private copy. When writing to its own memory, it also propagates the changes to the memory of other threads. Thus, this model does not have a total store order. Furthermore, read operations can be delayed until they are actually needed.
868-
869-
The write order seen by one thread can differ from the order seen by other threads because write operations can be reordered during propagation. However, reads and writes to the same memory address must still follow a total order. Therefore, the following litmus test cannot result in \monobox{r1 = 1}, \monobox{r2 = 2}, but \monobox{r3 = 2}, \monobox{r4 = 1}. Which write overwrites which must be visible to all threads. This guarantee is known as coherence. Without coherence, programming for such a system would be very difficult.
870-
871-
All the litmus tests mentioned above are allowed under the relaxed memory model of \textsc{Arm}, except for the following example. Neither \textsc{Arm}, x86-TSO, nor sequential consistency model would result in \monobox{r1 = 1}, \monobox{r2 = 2}, \monobox{r3 = 2}, and \monobox{r4 = 1}.
894+
As shown in figure \ref{hw-relaxed}, the \textsc{Arm} instruction set adopts a more relaxed memory model.
895+
Each thread maintains its own copy of the memory, and every read and write operation targets this private copy.
896+
When writing to its own memory, it also propagates the changes to the memory of other threads.
897+
Thus, this model does not have a total store order.
898+
Furthermore, read operations can be delayed until they are actually needed.
899+
900+
The write order seen by one thread can differ from the order seen by other threads because write operations can be reordered during propagation.
901+
However, reads and writes to the same memory address must still follow a total order.
902+
Therefore, the following litmus test cannot result in \monobox{r1 = 1}, \monobox{r2 = 2}, but \monobox{r3 = 2}, \monobox{r4 = 1}.
903+
Which write overwrites which must be visible to all threads.
904+
This guarantee is known as coherence.
905+
Without coherence, programming for such a system would be very difficult.
906+
907+
All the litmus tests mentioned above are allowed under the relaxed memory model of \textsc{Arm}, except for the following example.
908+
Neither \textsc{Arm}, x86-TSO, nor sequential consistency model would result in \monobox{r1 = 1}, \monobox{r2 = 2}, \monobox{r3 = 2}, and \monobox{r4 = 1}.
872909

873910
\begin{ccode}
874911
// Litmus Test: Coherence

0 commit comments

Comments
 (0)