Memory barrier

<h2 id="example">Example</h2>
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 <a href="/facts/Memory-mapped_I%2fO/PmLNFq01">memory-mapped peripherals</a>, 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 <a href="/facts/Pthreads/S8oH6pI9">pthreads</a> 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 <a href="/facts/Concurrency_(computer_science)/Ctnrrq4A">concurrently</a> on a <a href="/facts/Multi-core_processor/ABNb65hQ">multi-core processor</a>.
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 x and f both hold the value 0. The software thread running on processor #1 loops while the value of f is zero, then it prints the value of x. The software thread running on processor #2 stores the value 42 into x and then stores the value 1 into f. 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 <a href="/facts/Enforce_In-order_Execution_of_I%2fO/hSwg1dzk">eieio</a> 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.<a class="footnote-ref" id="fnref:1" href="#fn:1">1</a><a class="footnote-ref" id="fnref:2" href="#fn:2">2</a>
In the case of the <a href="/facts/ARM_architecture_family/SALsYA79">ARM architecture family</a>, the DMB,<a class="footnote-ref" id="fnref:3" href="#fn:3">3</a> DSB<a class="footnote-ref" id="fnref:4" href="#fn:4">4</a> and ISB<a class="footnote-ref" id="fnref:5" href="#fn:5">5</a> instructions are used.<a class="footnote-ref" id="fnref:6" href="#fn:6">6</a>
Thread #1 Core #1:

 while (f == 0);
 // Memory fence required here
 print x;

Thread #2 Core #2:

 x = 42;
 // Memory fence required here
 f = 1;

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 f to be updated before x, 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 x to be read before f 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 f to ensure that the new value of x is visible to other processors at or prior to the change in the value of f. Another important point is a memory barrier must also be inserted before thread #1's access to x to ensure the value of x is not read prior to seeing the change in the value of f.
Another example is when a driver performs the following sequence:

 prepare data for a hardware module
 // Memory fence required here
 trigger the hardware module to process the data

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 <a href="/facts/Double-checked_locking/VftRmHXu">double-checked locking</a>.

<h2 id="multithreaded-programming-and-memory-visibility">Multithreaded programming and memory visibility</h2>
See also: <a href="/facts/Memory_model_(programming)/RtDrDzjL">Memory model (programming)</a>
Multithreaded programs usually use synchronization primitives provided by a high-level programming environment—such as <a href="/facts/Java_(programming_language)/9ScgFyAL">Java</a> or <a href="/facts/.NET/PDMQdfFu">.NET</a>—or an <a href="/facts/Application_programming_interface/GMlN4vUr">application programming interface</a> (API) such as POSIX Threads or <a href="/facts/Windows_API/RRw4RtTu">Windows API</a>. Synchronization primitives such as <a href="/facts/Mutual_exclusion/1dwvCxDW">mutexes</a> and <a href="/facts/Semaphore_(programming)/BrE1W4Je">semaphores</a> are provided to synchronize access to resources from parallel threads of execution. These primitives are usually implemented with the memory barriers required to provide the expected memory visibility <a href="/facts/Semantics/1L4WwLAP">semantics</a>. In such environments explicit use of memory barriers is not generally necessary.

<h2 id="out-of-order-execution-versus-compiler-reordering-optimizations">Out-of-order execution versus compiler reordering optimizations</h2>
Memory barrier instructions address reordering effects only at the hardware level. Compilers may also reorder instructions as part of the <a href="/facts/Program_optimization/nXz6RpRM">program optimization</a> process. Although the effects on parallel program behavior can be similar in both cases, in general it is necessary to take separate measures to inhibit compiler reordering optimizations for data that may be shared by multiple threads of execution.
In <a href="/facts/C_(programming_language)/Ky2No763">C</a> and <a href="/facts/C%252B%252B/Et0F2qn9">C++</a>, the volatile keyword was intended to allow C and C++ programs to directly access memory-mapped I/O. Memory-mapped I/O generally requires that the reads and writes specified in source code happen in the exact order specified with no omissions. Omissions or reorderings of reads and writes by the compiler would break the communication between the program and the device accessed by memory-mapped I/O. A C or C++ compiler may not omit reads from and writes to volatile memory locations, nor may it reorder read/writes relative to other such actions for the same volatile location (variable). The keyword volatile does not guarantee a memory barrier to enforce cache-consistency. Therefore, the use of volatile alone is not sufficient to use a variable for inter-thread communication on all systems and processors.<a class="footnote-ref" id="fnref:7" href="#fn:7">7</a>
The C and C++ standards prior to C11 and C++11 do not address multiple threads (or multiple processors),<a class="footnote-ref" id="fnref:8" href="#fn:8">8</a> and as such, the usefulness of volatile depends on the compiler and hardware. Although volatile guarantees that the volatile reads and volatile writes will happen in the exact order specified in the source code, the compiler may generate code (or the CPU may re-order execution) such that a volatile read or write is reordered with regard to non-volatile reads or writes, thus limiting its usefulness as an inter-thread flag or mutex.

<h2 id="see-also">See also</h2>
<ul>
<li>Computer programming portal</li></ul>
<ul><li><a href="/facts/Lock-free_and_wait-free_algorithms/KhLDma0v">Lock-free and wait-free algorithms</a></li>
<li><a href="/facts/Meltdown_(security_vulnerability)/KVRY83cy">Meltdown (security vulnerability)</a></li></ul>

<h2 id="external-links">External links</h2>
<ul><li><a href="http://www.rdrop.com/users/paulmck/scalability/paper/whymb.2010.07.23a.pdf">Memory Barriers: a Hardware View for Software Hackers</a></li>
<li><a href="http://www.linuxjournal.com/article/8211">Linux kernel memory barrier issues on multiple types of CPUs</a></li>
<li><a href="https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/Documentation/memory-barriers.txt">Documentation on memory barriers in the Linux kernel</a></li>
<li><a href="http://www.oracle.com/technetwork/server-storage/solarisstudio/documentation/oss-compiler-barriers-176055.pdf">Handling Memory Ordering in Multithreaded Applications with Oracle Solaris Studio 12 Update 2: Part 1, Compiler Barriers</a></li>
<li><a href="http://www.oracle.com/technetwork/server-storage/solarisstudio/documentation/oss-memory-barriers-fences-176056.pdf">Handling Memory Ordering in Multithreaded Applications with Oracle Solaris Studio 12 Update 2: Part 2, Memory Barriers and Memory Fences</a></li>
<li><a href="https://lwn.net/Articles/573436/">User-space RCU: Memory-barrier menagerie</a></li></ul>

<h2 id="references">References</h2>

<ol>
<li id="fn:1">May, Cathy; Silha, Ed; Simpson, Eick; Warren, Hank (1993). The PowerPC Architecture: A Specification for a New Family of RISC Processors. Morgan Kaufmann Publishers. p. 350. ISBN 1-55860-316-6. <a href="1-55860-316-6" target="_blank">1-55860-316-6</a> <a href="#fnref:1" class="footnote-back-ref">↩</a></li>
<li id="fn:2">Kacmarcik, Cary (1995). Optimizing PowerPC Code. Addison-Wesley Publishing Company. p. 188. ISBN 0-201-40839-2. <a href="0-201-40839-2" target="_blank">0-201-40839-2</a> <a href="#fnref:2" class="footnote-back-ref">↩</a></li>
<li id="fn:3">"DMB". developer.arm.com. Retrieved January 12, 2025. <a href="https://developer.arm.com/documentation/ddi0602/2024-12/Base-Instructions/DMB--Data-memory-barrier-?lang=en" target="_blank">https://developer.arm.com/documentation/ddi0602/2024-12/Base-Instructions/DMB--Data-memory-barrier-?lang=en</a> <a href="#fnref:3" class="footnote-back-ref">↩</a></li>
<li id="fn:4">"DSB". developer.arm.com. Retrieved January 12, 2025. <a href="https://developer.arm.com/documentation/ddi0602/2024-12/Base-Instructions/DSB--Data-synchronization-barrier-?lang=en" target="_blank">https://developer.arm.com/documentation/ddi0602/2024-12/Base-Instructions/DSB--Data-synchronization-barrier-?lang=en</a> <a href="#fnref:4" class="footnote-back-ref">↩</a></li>
<li id="fn:5">"ISB". developer.arm.com. Retrieved January 12, 2025. <a href="https://developer.arm.com/documentation/ddi0602/2024-12/Base-Instructions/ISB--Instruction-synchronization-barrier-?lang=en" target="_blank">https://developer.arm.com/documentation/ddi0602/2024-12/Base-Instructions/ISB--Instruction-synchronization-barrier-?lang=en</a> <a href="#fnref:5" class="footnote-back-ref">↩</a></li>
<li id="fn:6">"DMB, DSB, and ISB". developer.arm.com. Retrieved January 12, 2025. <a href="https://developer.arm.com/documentation/dui0588/b/ARM-and-Thumb-Instructions/DMB--DSB--and-ISB?lang=en" target="_blank">https://developer.arm.com/documentation/dui0588/b/ARM-and-Thumb-Instructions/DMB--DSB--and-ISB?lang=en</a> <a href="#fnref:6" class="footnote-back-ref">↩</a></li>
<li id="fn:7">Corbet, Jonathan. "Why the 'Volatile' Type Class Should not Be Used". Kernel.org. Retrieved April 13, 2023. <a href="https://www.kernel.org/doc/html/latest/process/volatile-considered-harmful.html" target="_blank">https://www.kernel.org/doc/html/latest/process/volatile-considered-harmful.html</a> <a href="#fnref:7" class="footnote-back-ref">↩</a></li>
<li id="fn:8">Boehm, Hans (June 2005). Threads Cannot Be Implemented As a Library. Proceedings of the 2005 ACM SIGPLAN conference on Programming language design and implementation. Association for Computing Machinery. p. 261. CiteSeerX 10.1.1.308.5939. doi:10.1145/1065010.1065042. ISBN 1595930566. <a href="1595930566" target="_blank">1595930566</a> <a href="#fnref:8" class="footnote-back-ref">↩</a></li>
</ol>

Memory barrier open-in-new

Memory barrier