FlushFileBuffers是否需要跨多个进程同步文件数据？ [英] Is FlushFileBuffers required to sync file data across many processes?

问题描述

我有一个由多个进程读/写的文件，它们使用互斥锁来序列化读/写。

I have a file which is read/write by many processes, they use a mutex to serialize the read/writes.

是否需要我调用 FlushFileBuffers 在 WriteFile 之后 ProcessA 以便 ProcessB 会看到这些变化吗？或者 ProcessB 保证看到 ProcessA 所做的更改，假设此文件的操作系统磁盘缓存是在所有流程？在调用 WriteFile 之后，我没有在文件上调用 CloseHandle ，我在所有进程中保持打开但是它们有 FILE_SHARE_READ 和 FILE_SHARE_WRITE 传递给 CreateFile 的标志。

Is it required that I call FlushFileBuffers after WriteFile in ProcessA so that ProcessB would see these changes? Or would ProcessB be guaranteed to see the changes that ProcessA made, assuming the OS disk cache for this file is shared between all processes? After calling WriteFile I do not call CloseHandle on the file, I leave it open in all processes but they have the FILE_SHARE_READ and FILE_SHARE_WRITE flags passed to CreateFile.

这需要在Windows XP到Windows 8.1之间工作 - 我发现调用 FlushFileBuffers 会带来不可接受的性能瓶颈。 / p>

This is required to work across Windows XP to Windows 8.1 - I've found that calling FlushFileBuffers presents an unacceptable performance bottleneck.

推荐答案

具有文件的内存映射视图的进程可以直接访问磁盘缓存中的页面;访问与同一台机器上的所有其他进程保持一致，并且您的互斥锁足以进行同步。

Processes which have a memory-mapped view of the file have direct access to the page in the disk cache; accesses are coherent with all other processes on the same machine, and your mutex is sufficient for synchronization.

使用文件访问API的进程需要调用 FlushFileBuffers 以确保一致性。

Processes which use file access APIs need to call FlushFileBuffers to ensure coherency.

如果你无法摆脱IPC的共享文件（例如，你无法改变其中一个参与者），您至少可以将您控制的那些迁移到内存映射文件视图，以获得巨大的性能优势。

If you can't get away from shared files for IPC (for example, you can't change one of the participants), you can at least migrate the ones you do control to memory-mapped file views, for a big performance benefit.

这篇关于FlushFileBuffers是否需要跨多个进程同步文件数据？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！