Boost IPC 好用吗?
我对跨平台 IPC 的默认选择是 boost，但是当我询问它时，我看到它在两个不同的论坛中受到批评，这让我感到担忧.或许这只是一个巧合，那么对于 boost IPC 和选择跨平台 C++ IPC 库的总体思路是什么?
My default choice for cross-platform IPC would be boost, but I saw it criticised in two different forums when I asked about it and this concerned me. Perhaps this was simply a coincidence, so what are the thoughts on boost IPC and choosing a cross-platform C++ IPC library in general?
对于 Windows 开发者，我们使用 VC++ 2008 作为参考.
For Windows dev we're using VC++ 2008 for reference.
这是我看到的评论示例(现在找不到所有评论):
edit: here is an example of comments I've seen made (can't find them all right now):
为了提升，这是废话.至少在视窗.互斥体不使用 WinAPI，相反，他们创造了自己的基于文件的实现 (WinAPI =内核对象).如果你的程序崩溃文件不会被删除.下次启动您的程序时无法创建互斥锁，因为现有文件.
for boost, it's crap. At least on windows. The Mutexes don't use WinAPI, instead they create it's own File-Based implementation (WinAPI = Kernel-Objects). If your Program crashes the files won't be deleted. Next time your Programm is launched the mutex can't be created, because of the existing file.
推荐答案
从我有限的 Boost.Interprocess 经验来看，我没有遇到任何重大问题，但我无法真正评论性能.虽然它确实使用在程序文件夹之外创建的文件来完成它的工作，但它们都应该是内存映射的，这可以消除大多数性能问题.在任何情况下，当您使用 IPC 时，您都应该期待一些额外的性能开销.
From my limited experience with Boost.Interprocess, I didn't have any major problems but I can't really comment on performance. While it's true that it does use files created outside of your program's folder to do its stuff, they should all be memory mapped which negates most of the performance problems. In any case, when you're using IPC you should always expect some extra performance overhead.
至于您强调的??批评，可以删除已命名的互斥锁或任何其他命名资源，这些资源已被前一个进程遗留下来(请参阅静态 remove(const char*) 函数).公平地说，根据您的应用程序，正确使用可能会很棘手，这不是您在使用 Windows API 时必须处理的问题.另一方面，Windows API 不可移植.我的猜测是他们使用文件(即使存在更好的替代方案)来保持库的界面和行为在不同平台上保持一致.
As for the criticism you highlighted, it is possible to remove a named mutex or any other named resources that has been left lying around by a previous process (see the static remove(const char*) function). To be fair, depending on your application, it might be tricky to use correctly which is not something you have to deal with when using the Windows API. On the other hand, the Windows API isn't portable. My guess is that they use files (even when better alternative exists) to keep the interface and behaviour of the library consistent across different platforms.
无论如何，命名互斥只是库提供的一小部分.更有用的功能之一是它提供了它的 共享内存区域的自己的内存管理器，其中包括 STL 分配器.我个人觉得使用它提供的高级结构比使用原始内存更令人愉快.
Anyway, named mutexes is only small part of what the library provides. One of the more useful features is that it provides its own memory managers for the shared memory region which includes STL allocators. I personally find it more pleasant to work with the high level constructs it provides then with raw memory.
更新:我在 Boost 文档中做了更多的挖掘，发现了各种有趣的消息:
UPDATE: I did some more digging the in the Boost documentation and I came across various interesting tid bits:
此页面提供了更多信息有关库的实现和性能的详细信息，但不包括实现原理.
This page gives a bit more detail about the implementation and the performances of the library but doesn't include an implementation rationale.
此链接 明确指出他们的 Windows 互斥体实现可以使用一些工作(版本 1.46).如果您在 boostinterprocesssync 文件夹中进一步挖掘，您会注意到另外两个名为 posix 和 emulation 的文件夹.这两个都包含同步原语的实现细节.interprocess_mutex::lock 的 posix 实现是您所期望的，但仿真实现非常基本:
This link clearly states that their Windows mutex implementation could use some work (version 1.46). If you dig a little further in the boostinterprocesssync folder, you'll notice two more folders named posix and emulation. Both of these contains the implementation details for the synchronisation primitive. The posix implementation for interprocess_mutex::lock is what you'd expect but the emulation implementation is pretty basic:
// Taken from Boost 1.40.
inline void interprocess_mutex::lock(void)
{
do{
boost::uint32_t prev_s = detail::atomic_cas32(const_cast<boost::uint32_t*>(&m_s), 1, 0);
if (m_s == 1 && prev_s == 0){
break;
}
// relinquish current timeslice
detail::thread_yield();
}while (true);
}
因此，从表面上看，他们的目标是支持 Posix，并将其他所有内容放入使用内存映射文件的仿真层中.如果您想知道他们为什么不提供专门的 Windows 实现，那么我建议您询问 Boost 邮件列表(我在文档中找不到任何内容).
So by the looks of it, they aimed for Posix support and blobbed everything else into an emulation layer which uses memory mapped files. If you want to know why they don't provide a specialised Windows implementation then I suggest asking the Boost mailing list (I couldn't find anything in the doc).
相关文章