Editing Memory barrier (section)

==Example==
When a program runs on a single-CPU machine, the hardware performs the necessary bookkeeping to ensure that the program executes as if all memory operations were performed in the order specified by the programmer (program order), so memory barriers are not necessary. However, when the memory is shared with multiple devices, such as other CPUs in a multiprocessor system, or [[Memory-mapped I/O|memory-mapped peripherals]], out-of-order access may affect program behavior. For example, a second CPU may see memory changes made by the first CPU in a sequence that differs from program order.

A program is run via a process which can be multi-threaded (i.e. a software thread such as [[pthreads]] as opposed to a hardware thread).  Different processes do not share a memory space so this discussion does not apply to two programs, each one running in a different process (hence a different memory space).  It applies to two or more (software) threads running in a single process (i.e. a single memory space where multiple software threads share a single memory space).  Multiple software threads, within a single process, may run [[Concurrency (computer science)|concurrently]] on a [[multi-core processor]].

The following multi-threaded program, running on a multi-core processor gives an example of how such out-of-order execution can affect program behavior:

Initially, memory locations <code>x</code> and <code>f</code> both hold the value <code>0</code>. The software thread running on processor #1 loops while the value of <code>f</code> is zero, then it prints the value of <code>x</code>. The software thread running on processor #2 stores the value <code>42</code> into <code>x</code> and then stores the value <code>1</code> into <code>f</code>. Pseudo-code for the two program fragments is shown below.

The steps of the program correspond to individual processor instructions.

In the case of the PowerPC processor, the <code>[[Enforce In-order Execution of I/O|eieio]]</code> instruction ensures, as memory fence, that any load or store operations previously initiated by the processor are fully completed with respect to the main memory before any subsequent load or store operations initiated by the processor access the main memory.<ref>{{cite book |title=The PowerPC Architecture: A Specification for a New Family of RISC Processors |last1=May |first1=Cathy |last2=Silha |first2=Ed |last3=Simpson |first3=Eick |last4=Warren |first4=Hank |isbn=1-55860-316-6 |date=1993 |publisher=Morgan Kaufmann Publishers |page=350 }}</ref><ref>{{cite book |title=Optimizing PowerPC Code |last=Kacmarcik |first=Cary |isbn=0-201-40839-2 |date=1995 |publisher=Addison-Wesley Publishing Company |page=188 }}</ref>

In the case of the [[ARM architecture family]], the <code>DMB</code>,<ref>{{cite web |title=DMB |url=https://developer.arm.com/documentation/ddi0602/2024-12/Base-Instructions/DMB--Data-memory-barrier-?lang=en |website=developer.arm.com |access-date=January 12, 2025 }}</ref> <code>DSB</code><ref>{{cite web |title=DSB |url=https://developer.arm.com/documentation/ddi0602/2024-12/Base-Instructions/DSB--Data-synchronization-barrier-?lang=en |website=developer.arm.com |access-date=January 12, 2025}}</ref> and <code>ISB</code><ref>{{cite web |title=ISB |url=https://developer.arm.com/documentation/ddi0602/2024-12/Base-Instructions/ISB--Instruction-synchronization-barrier-?lang=en |website=developer.arm.com |access-date=January 12, 2025 }}</ref> instructions are used.<ref>{{cite web |title=DMB, DSB, and ISB |url=https://developer.arm.com/documentation/dui0588/b/ARM-and-Thumb-Instructions/DMB--DSB--and-ISB?lang=en |website=developer.arm.com |access-date=January 12, 2025 }}</ref>

Thread #1  Core #1:
<syntaxhighlight lang="cpp">
 while (f == 0);
 // Memory fence required here
 print x;
</syntaxhighlight>

Thread #2  Core #2:
<syntaxhighlight lang="cpp">
 x = 42;
 // Memory fence required here
 f = 1;
</syntaxhighlight>

One might expect the print statement to always print the number "42"; however, if thread #2's store operations are executed out-of-order, it is possible for <code>f</code> to be updated {{em|before}} <code>x</code>, and the print statement might therefore print "0". Similarly, thread #1's load operations may be executed out-of-order and it is possible for <code>x</code> to be read {{em|before}} <code>f</code> is checked, and again the print statement might therefore print an unexpected value.  For most programs neither of these situations is acceptable. A memory barrier must be inserted before thread #2's assignment to <code>f</code> to ensure that the new value of <code>x</code> is visible to other processors at or prior to the change in the value of <code>f</code>.  Another important point is a memory barrier must also be inserted before thread #1's access to <code>x</code> to ensure the value of <code>x</code> is not read prior to seeing the change in the value of <code>f</code>.

Another example is when a driver performs the following sequence:
<syntaxhighlight lang="cpp">
 prepare data for a hardware module
 // Memory fence required here
 trigger the hardware module to process the data
</syntaxhighlight>
If the processor's store operations are executed out-of-order, the hardware module may be triggered before data is ready in memory.

For another illustrative example (a non-trivial one that arises in actual practice), see [[double-checked locking]].