顺序非易失性加载在内存重映射场景下的正确性及相关未定义行为问题

问题描述 #

已知编译器可将多个non-volatile加载合并为单次加载，请问内存映射函数是否会因此引发未定义行为？举例代码如下：

int k = *p;

unmapFile(fm, fileHandle1);//解除映射的内存包含p指向的地址

//p不再有效，指向未映射的虚拟地址

mapFile(fm, fileHanlde2);//p现在指向另一个文件映射区域内的地址

int j = *p;

//此处使用k和j

两次对p的解引用是否会被合并，导致代码行为不可预测？另外说明：我了解POSIX和Windows下的文件映射函数不允许指定映射起始地址，这只是简化的假设场景，实际存在此类范式的用例。同时请问：非易失性加载在内存重映射附近使用时，能否通过保证执行顺序来确保正确性？

解答 #

1. 加载合并风险与未定义行为 #

编译器对non-volatile变量的加载合并优化，是基于**“同一虚拟地址对应的内存内容不会被编译器无法感知的外部操作（如内核的内存映射变更）修改”**的核心假设。

在你给出的示例中，如果p未被volatile限定，编译器完全可能将两次对*p的加载操作合并——比如只在第一次读取*p的值，然后将这个值同时赋值给k和j。但实际上中间的unmapFile和mapFile操作已经彻底改变了p指向的虚拟地址对应的物理内存内容，这种合并会导致j拿到的是旧映射区域的值，完全不符合代码逻辑预期，这就属于未定义行为——因为代码打破了编译器的优化前提，导致生成的机器码逻辑错误。

2. 执行顺序与正确性保证 #

要在这类场景下保证代码行为正确，核心是让编译器感知到“内存映射操作会修改虚拟地址对应的内存内容”，从而禁止跨操作的加载合并。常见的实现方式有两种：

• 给指针p添加volatile限定：volatile会告诉编译器，该地址的内容可能被外部操作异步修改，因此每次对*p的访问都必须重新从内存加载，不能进行合并优化。
• 插入编译器内存屏障：在unmapFile和mapFile调用前后，插入编译器级别的内存屏障（比如GCC的__asm__ __volatile__("" : : : "memory")）。内存屏障会强制编译器将屏障之前的所有内存操作完成后再执行后续操作，同时告知编译器屏障前后的内存内容可能发生了外部修改，必须重新加载相关地址的值。

需要注意的是：无论是否使用volatile，在unmapFile之后到mapFile完成之前，p指向的是未映射的虚拟地址，此时对*p的解引用本身就是未定义行为，这段逻辑必须确保不会被执行。

内容的提问来源于stack exchange，提问作者Badasahog