Editing Memory barrier (section)

==Out-of-order execution versus compiler reordering optimizations==
Memory barrier instructions address reordering effects only at the hardware level. Compilers may also reorder instructions as part of the [[program optimization]] 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 [[C (programming language)|C]] and [[C++]], the {{mono|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 {{mono|volatile}} {{em|does not guarantee a memory barrier}} to enforce cache-consistency. Therefore, the use of {{mono|volatile}} alone is not sufficient to use a variable for inter-thread communication on all systems and processors.<ref>{{cite web |last=Corbet |first=Jonathan |url=https://www.kernel.org/doc/html/latest/process/volatile-considered-harmful.html |title=Why the 'Volatile' Type Class Should not Be Used |website=Kernel.org |access-date=April 13, 2023 }}</ref>

The C and C++ standards prior to C11 and C++11 do not address multiple threads (or multiple processors),<ref>{{cite conference |last=Boehm |first=Hans |title=Threads Cannot Be Implemented As a Library |work=Proceedings of the 2005 ACM SIGPLAN conference on Programming language design and implementation |publisher=[[Association for Computing Machinery]] |date=June 2005 |page=261
 | url=http://dl.acm.org/citation.cfm?id=1065042
  | doi=10.1145/1065010.1065042 | isbn=1595930566
 | citeseerx=10.1.1.308.5939
  }}</ref> and as such, the usefulness of {{mono|volatile}} depends on the compiler and hardware. Although {{mono|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.