The memory barrier mainly solves the problem of Compiler Optimization and execution of CPU out of order.
When the compiler is optimizing, the generated Assembly commands may be different from the execution sequence of C language programs. When the program is executed strictly in the C language sequence, it is explicitly told that the compilation does not need to be optimized, in Linux, this is done through the barrier () Macro, which relies on the volidate keyword and the memory keyword. The former tells the instructions around barrier () Compilation not to be optimized, the latter is used to tell the compiler to compile code to change the value in the memory. The compiler should use the new value in the memory instead of the old value saved in the register.
Similarly, CPU execution improves performance through disordered execution. The commands in the Assembly are not necessarily executed in the order we see. In Linux, MB () macros are used to ensure the execution sequence. The specific method is through the mfence/lfence commands (they were introduced after 4, not available in early x86) and x86 commands with serial characteristics (there are many such commands, for example, the lock commands, I/O commands, operation control registers, system registers, debugging register commands, and iret commands used in Linux ). To put it simply, if the MB ()/RMB ()/WMB () macro is inserted somewhere in the program, the program before the macro must be executed first than the program after the macro, to achieve serialization. The implementation of WMB is similar to that of barrier () because on the X86 platform, write memory operations are not executed in disorder.
In fact, on the rsic platform, these serial jobs have dedicated commands explicitly completed by programmers, such as calling serial commands wherever needed, unlike x86, there are so many implicit serial-specific commands (such as lock commands ). Therefore, it is easier for a friend who works on the PROTEUS platform to understand serialized operations.