boost::interprocess::scoped_lock应用程序在锁内崩溃

boost::interprocess::scoped_lock application crash inside lock

本文关键字：崩溃 应用程序 lock interprocess scoped boost      更新时间：2023-10-16

我正在使用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();
        }
    }

这对我来说似乎完全符合逻辑：）

当应用程序崩溃时，映射到操作系统进程间通信机制（IPC）的互斥对象不会释放。当应用程序重新启动时，它试图获取互斥对象，但没有成功！

我想您的应用程序有不同的子系统（进程）需要同步。

您必须设计一个全局策略，以防某个子系统崩溃，从而正确管理锁。例如，如果某个子系统崩溃，它应该在启动时尝试解锁互斥锁。当其他子系统使用该锁时，这可能很棘手。超时也有帮助。在任何情况下，您都必须在设计策略时考虑到，在锁定互斥对象时，任何进程都可能崩溃。。。

当然，如果您不需要进程间锁定，请使用简单的作用域锁定：）

my2c

相关文章：