问题描述
我已经完成了有关 boost::interprocess::file_lock ，它似乎可以做很多事情(支持共享和独占锁定，并在进程崩溃或退出时被解锁).
I've done some reading about boost::interprocess::file_lock and it seems to do pretty much what I'm after (support shareable and exclusive locking, and being unlocked if the process crashes or exits).
我不确定的一件事是，文件做什么是什么?例如，我可以使用0字节长的文件吗? boost::interprocess是否将任何内容写入其中?还是所有系统都在乎它的存在?
One thing I'm not sure about though, is what does it do to the file? Can I use for example a file of 0 bytes long? Does boost::interprocess write anything into it? Or is its presence all the system cares about?
我一直在使用boost::interprocess一段时间来可靠地对文件进行内存映射并写入文件，现在我需要进行多进程处理并确保对此文件的读写操作受到保护； file_lock似乎确实可行，我只是想知道是否现在需要添加另一个文件用作互斥体.
I've been using boost::interprocess now for some time to reliably memory map a file and write into it, now I need to go multiprocess and ensure that reads and writes to this file are protected; file_lock does seem the way to go, I just wonder if I now need to add another file to use as a mutex.
预先感谢
推荐答案
Boost对文件不执行任何操作，它依靠操作系统来完成该工作.支持内存映射文件是按需分页的虚拟内存操作系统的一般功能.像Windows，Linux，OSX.内存通常由分页文件支持，由您选择的特定文件支持它只是一小步. Boost仅提供了一个独立于平台的适配器，仅此而已.
Boost does not do anything with the file, it relies on the operating system to get that job done. Support for memory mapped files is a generic capability of a demand-paged virtual memory operating system. Like Windows, Linux, OSX. Memory is normally backed by the paging file, having it backed by a specific file you select is but a small step. Boost just provides a platform-independent adapter, nothing more.
您将需要查看相关的OS文档页面，以了解可能的情况以及在做一些不寻常的事情时期望它如何工作.对于Linux和OSX，您需要查看mmap手册页.对于Windows，请查看CreatefileMapping.
You'll want to take a look at the relevant OS documentation pages to see what's possible and how it is expected to work when you do something unusual. For Linux and OSX you'll want to look at the mmap man pages. For Windows look at CreatefileMapping.
是的，您几乎总是需要仲裁对内存映射文件的访问，因此，例如，一个进程仅在另一进程完成写入数据时才尝试读取数据.最合适的同步原语是不是 file_lock(操作系统已锁定文件)，它是一个名为互斥体.例如使用boost的 named_mutex类.
Yes, you almost always need to arbitrate access to the memory mapped file so for example one process will only attempt to read the data when the other process finished writing it. The most suitable synchronization primitive for that is not a file_lock (the OS already locks the file), it is a named mutex. Use, say, boost's named_mutex class.
请记住，这是一个非常底层互操作机制，并且没有任何便利.到您添加所有必需的同步时，您已经完成了操作系统已使用命名管道或本地环回套接字执行的操作的一半.如果您发现必须将数据复制到映射的视图中(因为它不容易调整大小)，这并不罕见，那么您就失去了所有好处.
Do keep in mind that this is a very low-level interop mechanism and comes without any conveniences whatsoever. By the time you add all of the required synchronization, you're half-way to what the OS already does with a named pipe or local-loopback socket. If you discover that you have to copy data into the mapped view, not uncommon since it is not easily resizable, then you've lost all benefits.
这篇关于boost进程间file_lock实际上对目标文件有什么作用?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持！