interprocess::named_upgradable_mutex - 如果进程被杀死，则保持锁定状态
我正在使用 boost::interprocess::named_upgradable_mutex 来同步一些进程。
我使用 boost::interprocess::sharable_lock 和 boost::interprocess::scoped_lock 来锁定互斥锁。
测试同步时，只要进程正常工作并且正常关闭，看起来就很好。
但是，我注意到，如果进程在持有互斥锁时被终止（例如通过任务管理器），则互斥锁将保持锁定状态。
知道我如何处理流程失败吗？
我考虑过使用 timed_lock() 以防万一......还有其他想法吗？
I'm using boost::interprocess::named_upgradable_mutex to synchronize a few processes.
I'm using boost::interprocess::sharable_lock and boost::interprocess::scoped_lock to lock the mutex.
When testing the synchronization, it looks fine as long as the processes are working, and are closed normally.
But, I've notices that if a process is killed (via TaskManager for example) while holding the mutex, the mutex remains locked.
Any idea how i can handle process failures ?
I've thought about using timed_lock() just in case... any other ideas?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
你正在解决的是症状而不是问题。互斥体的目的是允许进程或线程将共享数据置于不一致状态。如果进程在持有互斥体时死亡，则共享数据仍处于不一致状态。问题是如何将共享数据返回到一致状态，而不是如何解锁互斥体。
当您将共享数据返回到一致状态时，请在返回到一致状态的数据中包含互斥锁或锁。最简单的方法是删除现有的锁并创建一个新的锁。您可能必须对共享数据执行相同的操作。
如果您确实需要这样做，我建议您可能没有使用正确的工具来完成这项工作。
You're working on the symptom rather than the problem. The purpose of a mutex is to allow a process or thread to put shared data into an inconsistent state. If the process dies while holding the mutex, the shared data is still in an inconsistent state. The problem is how to return the shared data to a consistent state, not how to unlock the mutex.
When you return the shared data to a consistent state, include the mutex or lock in the data you return to a consistent state. The simplest way is to remove the existing lock and create a new one. You will likely have to do the same thing for the shared data.
If you really need to do this though, I'd suggest you're probably not using the right tool for the job.
如果您出于某种原因杀死了您的应用程序，您可以通过从 Windows 注销或执行命令 mutex.unlock(); 来解锁此锁。
In case you kill your app for some reason, you can unlock this lock either by logout from Windows, or by executing command mutex.unlock();