boost interprocess file_lock 实际上对目标文件做了啥？

Posted 2023-02-21

【中文标题】boost interprocess file_lock 实际上对目标文件做了啥？

【英文标题】：What does boost interprocess file_lock actually do with the target file?boost interprocess file_lock 实际上对目标文件做了什么？

【发布时间】：2015-02-07 12:57:33

【问题描述】：

我已经阅读了一些关于 boost::interprocess::file_lock 的内容，它似乎完成了我所追求的工作（支持可共享和独占锁定，并在进程崩溃或退出时解锁）。

我不确定的一件事是，它对文件做什么？例如，我可以使用 0 字节长的文件吗？ boost::interprocess 是否在其中写入任何内容？还是系统都关心它的存在？

我已经使用boost::interprocess 来可靠地映射文件并写入文件已有一段时间了，现在我需要进行多进程并确保对该文件的读写受到保护； file_lock 似乎确实可行，我只是想知道我现在是否需要添加另一个文件以用作互斥体。

提前致谢

【参考方案1】：

它对文件做了什么？

Boost 不对文件做任何事情，它依赖于操作系统来完成这项工作。对内存映射文件的支持是按需分页虚拟内存操作系统的通用功能。像 Windows、Linux、OSX。内存通常由页面文件支持，由您选择的特定文件支持只是一小步。 Boost 只是提供了一个独立于平台的适配器，仅此而已。

您需要查看相关的操作系统文档页面，了解可能发生的情况以及当您执行不寻常的操作时它应该如何工作。对于 Linux 和 OSX，您需要查看 mmap 手册页。对于 Windows，请查看 CreatefileMapping。

file_lock 似乎是要走的路

是的，您几乎总是需要仲裁对内存映射文件的访问，因此例如一个进程只会在另一个进程完成写入数据时尝试读取数据。最合适的同步原语是不是 file_lock（操作系统已经锁定了文件），它是一个命名的互斥锁。比如说，使用 boost 的named_mutex class。

请记住，这是一个非常低级互操作机制，没有任何便利。当您添加所有必需的同步时，您已经完成了操作系统对命名管道或本地环回套接字所做的工作的一半。如果您发现必须将数据复制到映射视图中，这种情况并不少见，因为它不容易调整大小，那么您就失去了所有好处。

【讨论】：

谢谢 Hans - 我想我真正要问的是 - 使用内存映射文件作为 file_lock 构造函数的参数是否安全？

不需要锁定文件，操作系统已经这样做了。如果您需要仲裁对 mmf 的访问（几乎总是需要），那么请改用 named_mutex。

好的 - 我担心进程挂在互斥体上并崩溃

@DaveF 我会再调查一下。我记得有一些非常烦人的边缘情况，当然可以修复，但并不像人们想要的那样微不足道（参见例如this answer to "How to limit the number of running instances in C++"）。那是一个名字 Semaphore，但它显示了同样的困境。

@sehe 是的，这是一个棘手的问题；我故意停止了 find_or_construct 中的进程，而它锁定了互斥锁，然后再次运行该进程 - 它挂起锁定 find_or_construct 中的互斥锁。所以这当然不是直截了当的。