在刷新和取消映射之前，我是否需要同步从不同线程对内存映射文件的写入？

Question

假设我有内存映射文件并从不同的线程写入它（写入永远不会重叠并且彼此独立）。我想将已写入的数据与磁盘同步并执行

msync

或

FlushViewOfFile

，然后取消映射文件。

我是否需要将写入线程与刷新线程同步，例如在写入器上使用释放内存栅栏并在刷新器上使用获取栅栏？我担心此时某些写入仍会在 CPU 缓存中，而不是在主内存中。

CPU 和操作系统是否保证仍在 CPU 缓存上的写入最终会进入磁盘，或者我应该首先确保写入到达主 RAM，然后才刷新并取消映射文件？

我的线程不会从映射页面读取数据，如果可能的话，我只想使用宽松的原子操作来跟踪我的数据。

我尝试做的伪代码：

static NUM_WRITERS: AtomicUint = 0;
static CURRENT_OFFSET: AtomicUint = 0;

fn some_thread_fn(void* buffer, payload: &[byte]){
   NUM_WRITERS.fetch_add(1, memory_order_relaxed);
   offset = CURRENT_OFFSET.fetch_add(payload_size, memory_order_relaxed);
   void* dst = buffer + offset;
   memcpy(dst, payload, payload_size);
   
   // Do I need memory fence or fetch_sub(Release) here?
   compiler_fence(memory_order_release); // Prevent compiler from reordering instructions
   NUM_WRITERS.fetch_sub(1, memory_order_relaxed);

   if offset + payload_size < buffer_size {
      // Some other thread is responsible for unmapping.
      return;
   }

   while (NUM_WRITERS.load(relaxed) > 0) {
      mm_pause();
   }

   // Do I need acquire memory fence here?
   compiler_fence(memory_order_acquire); // Prevent compiler from reordering instructions
   flush_async(buffer);
   unmap(buffer);
}

Answer 1

所有商店都需要发生-在

munmap

之前。除非系统在此之前崩溃，否则它将被写入磁盘。对于受

msync

影响的数据，请确保写入（分配/memcpy）发生在该地址范围上的

msync

之前。

在

fdatasync

 之后的 fd 上的 

munmap

将是确保所有脏数据尽快写入磁盘的更简单方法，除非您有 不想 想要同步的文件的其他区域。如果没有任何手动同步，页面缓存中的脏页会在超时（例如 15 秒）后排队等待写回磁盘。

“sequenced-before”是“happens-before”的一种足够强大的形式。例如，在单个线程内，页表条目中的“脏”标志位将被该线程的存储指令修改的任何后续内核代码（例如在msync

系统调用期间）看到。 （或者通过您同步的任何其他线程。）

我认为在你的情况下，是的，你确实需要

NUM_WRITERS.fetch_sub(1, memory_order_release);

 为每个线程，并且 

while (NUM_WRITERS.load(acquire) > 0) { pause }

 为到达旋转等待循环进行清理的一个线程。 

mm_pause()

 是 x86 特定的；在 x86 上，

acquire

 加载是免费的，与 

relaxed

 相同。所有 RMW 都需要 

lock

，例如

lock add

，同样的组件对于

seq_cst

来说足够强大。如果您计划移植到其他 ISA，那么请放心，AArch64 具有相对高效的 

acquire

 和 

release

。

relaxed

可能在大多数情况下都有效，但理论上会允许该线程在其他线程到达存储指令之前

munmap

并使页表条目无效，从而导致错误。或者更合理的是丢失数据。

---

您不需要手动

atomic_signal_fence

（又名

compiler_barrier

），因为编译器已经无法将存储移动到可能读取存储数据的函数调用的函数之外。 （就像 

arr[i] = 1; foo(arr)

，其中 

foo

 是 

msync

 或 

munmap

，出于完全相同的原因，CPU 不知道的用户定义函数是安全的。）执行乱序执行的 CPU 将保留按程序顺序运行的单个线程的错觉。

---

如果每次写入都具有页面粒度，则可以让每个线程在其写入的页面上执行自己的

msync

。如果写入小于页面，这就不太好了，因为您会为同一页面触发多个磁盘 I/O。