boost :: interprocess :: named_mutex与CreateMutex [英] boost::interprocess::named_mutex vs CreateMutex
问题描述
我想从CreatMutex切换到boost::interprocess::named_mutex以将我的应用程序限制为单个实例.当应用程序运行并结束时，这两种方法都可以工作.但是，当应用程序崩溃并使用boost::interprocess::named_mutex时，锁不会释放.我可以使用两个name_mutex来解决该问题，但我不太了解这个问题.
I want to switch from CreatMutex to boost::interprocess::named_mutex to limit my application to a single instance. Both methods works when the application runs and ends just fine. However, the lock is not released when the application crashes and using boost::interprocess::named_mutex. I could resolve that issue by using two name_mutex but I don't really understand the issue.
为什么在应用程序崩溃时未释放boost::interprocess::named_mutex的锁，但是它随CreatMutex一起释放?有什么区别?
Why is the lock for boost::interprocess::named_mutex not released when the application crashes but it is release with CreatMutex? What's the difference?
boost::interprocess::named_mutex mutex(boost::interprocess::open_or_create, "my_mutex");
boost::interprocess::scoped_lock<boost::interprocess::named_mutex> lock(mutex, boost::interprocess::try_to_lock);
if(!lock) {
return 1; //exit
}
//application may crash here.
boost::interprocess::named_mutex::remove("my_mutex");
return 1; //exit
推荐答案
注意事项:我没有花很多时间在boost::interprocess上，因此该信息仅来自对源代码的快速检查. .也就是说，我已经使用了很多Windows同步API，所以这里...
Caveat: I've not spent much time with boost::interprocess, so this information is just from a quick inspection of the source. That said, I've used the Windows synchronisation API's a lot, so here goes...
两种进程间同步方法之间的主要区别是对象在系统中的存在方式.
The main difference between the two methods of interprocess synchronisation is how the object exists within the system.
使用boost::interprocess::named_mutex以及特定于系统的互斥锁，它看起来像是在系统上作为文件创建了同步对象.该文件的位置基于注册表项(请参见注释1)(至少在Boost 1.54.0中)...... 最有可能位于Common Application Data文件夹下(请参见注释2).应用程序崩溃时，就您而言，此文件不会被删除.我不确定这是否是设计使然...但是，在应用程序崩溃的情况下，最好不要弄乱文件系统，以防万一.
With boost::interprocess::named_mutex, as well as a system-specific mutex, it looks like a synchronisation object is created as a file on the system. The location of the file is based on Registry entries (see note 1) (at least in Boost 1.54.0)... it's most likely located under the Common Application Data folder (see note 2). When the aplication crashes, this file is, in your case, not removed. I'm not sure if this is by design... however in the case of an application crash, it's perhaps best not to mess with the file system, just in case.
相反，当您使用CreateMutex时，将在内核模式下创建一个对象，可以通过多个应用程序访问已命名的互斥对象.通过在创建互斥对象时指定其名称，可以得到该互斥对象的句柄，而在其上调用CloseHandle则将丢失该句柄.当没有更多的句柄引用该互斥对象时，该对象将被破坏.
Conversely, when you use CreateMutex, an object is created at the kernel mode, which for named mutexes can be accessed by several applications. You get a handle to the Mutex by specifying the name when you create it, and you lose the handle when you call CloseHandle on it. The mutex object is destroyed when there are no more handles referencing it.
重要的部分在文档:
进程终止时，系统会自动关闭句柄.互斥对象的最后一个句柄关闭时，该对象将被破坏.
The system closes the handle automatically when the process terminates. The mutex object is destroyed when its last handle has been closed.
这基本上意味着Windows将在您的应用程序后清理.
This basically means that Windows will clean up after your application.
请注意，如果您不执行ReleaseMutex，并且您的应用程序在死亡时拥有互斥锁，则有可能/有可能等待线程或进程看到该互斥锁已被放弃(WaitForSingleObject返回WAIT_ABANDONED)，并将获得所有权.
Note that if you don't perform a ReleaseMutex, and your application owns the mutex when it dies, then it's possible/likely that a waiting thread or process would see that the mutex had been abandoned (WaitForSingleObject returns WAIT_ABANDONED), and would gain ownership.
很抱歉没有提供解决方案，但希望它能回答您有关两个系统为何行为不同的问题.
I apologise for not providing a solution, but I hope it answers your question about why the two systems act differently.
-
顺便说一句，使用注册表项来获取此信息是可怕的-使用
SHGetKnownFolderPath会更安全，并且更具前瞻性.但是我离题了.
Just as an aside, using registry entries to get this information is horrible - it would be safer, and more future-proof, to use
SHGetKnownFolderPath. But I digress.
取决于您的操作系统版本，该名称可能是%ALLUSERSPROFILE%\Application Data\boost.interprocess或ProgramData\boost.interprocess，或者完全是其他位置.
Depending on your OS version, this could be %ALLUSERSPROFILE%\Application Data\boost.interprocess or ProgramData\boost.interprocess, or somewhere else entirely.
这篇关于boost :: interprocess :: named_mutex与CreateMutex的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
