c – boost :: interprocess :: scoped_lock应用程序在锁内部崩
发布时间:2020-12-16 07:25:44 所属栏目:百科 来源:网络整理
导读:我正在使用boost :: interprocess :: scoped_lock,如果应用程序由于某种原因在范围内发生故障,则不会释放互斥锁. 下次执行应用程序时(不重新启动计算机),互斥锁被锁定. 这打算如何工作? 我举一个下面代码的简单例子. { boost::interprocess::named_mutex lo
我正在使用boost :: interprocess :: scoped_lock,如果应用程序由于某种原因在范围内发生故障,则不会释放互斥锁.
下次执行应用程序时(不重新启动计算机),互斥锁被锁定. 这打算如何工作? { boost::interprocess::named_mutex lockMutex(boost::interprocess::open_or_create,"lockName"); boost::interprocess::scoped_lock<boost::interprocess::named_mutex> lock(lockMutex); //crash here } 我最终做了一个像下面这样的超时.谁能想出一个不限制锁定时间的解决方案? boost::interprocess::named_mutex named_mtx(boost::interprocess::open_or_create,lockName.c_str()); while(true) { if(named_mtx.try_lock()) { break; } if(!named_mtx.timed_lock(boost::get_system_time() + boost::posix_time::milliseconds(TIMEOUT_MILLISECONDS))) { named_mtx.unlock(); } } 解决方法
这对我来说似乎完全合乎逻辑:)
当您的应用程序崩溃时,映射到您的OS进程间通信机制(IPC)的互斥锁不会被释放.当您的应用程序重新启动时,它会尝试获取互斥锁而不会成功! 我想你的应用程序有不同的需要同步的子系统(进程). 如果您的某个子系统崩溃,您必须设计一个全局策略来正确管理锁.例如,如果您的某个子系统崩溃,它应该在启动时尝试解锁互斥锁.它可能很棘手,因为其他子系统使用该锁.超时也可以提供帮助.在任何情况下,您必须设计策略,记住任何进程在锁定互斥锁时都可能崩溃… 当然,如果您不需要进程间锁定,请使用简单的作用域锁定:) MY2C (编辑:李大同) 【声明】本站内容均来自网络,其相关言论仅代表作者个人观点,不代表本站立场。若无意侵犯到您的权利,请及时与联系站长删除相关内容! |