【问题标题】:How to avoid scenario where Process2 keeps waiting for Process1 to release the named_mutex如何避免 Process2 一直等待 Process1 释放 named_mutex 的情况
【发布时间】:2019-09-10 17:47:50
【问题描述】:

我有几个进程,但当时只有一个应该在运行。这意味着假设 Process1 正在运行,如果 Process2 启动,那么 Process2 应该等到 Process1做完了。我正在考虑使用如下代码为此boost named_mutex

#include <iostream>
#include <boost/interprocess/sync/named_mutex.hpp>

using namespace boost::interprocess;

int main()
{
    named_mutex mutex(open_or_create, "some_name");

    try
    {
        mutex.lock();

        // Do work

        mutex.unlock();
    }
    catch (const std::exception& ex)
    {
        mutex.unlock();
        std::cout << ex.what();
    }
}

问题:
1. 如果Process1 遇到任何已处理/未处理的异常,我想确保不会出现Process2 饿死获取锁的情况?
2. C++ 中是否有任何类似 C# 的 finally 机制可以在这个用例中有所帮助?

【问题讨论】:

  • 如果 process1 终止 - 进程中的所有线程都终止,包括拥有互斥锁的线程。结果互斥锁将被释放,下一个服务员(比如 process2 线程)成为新的所有者 - 开始运行。但是如果 process1 挂起而不是终止而不是在挂起之前直接释放互斥锁 - 当然另一个进程将无限等待
  • 好点,我猜使用 mutex.time_lock() 将解决挂起的情况?
  • 不,挂起的场景没有任何解决方案。从某种意义上说,您当然可以等待互斥锁不是无限的,而只能等待一段时间,但是如果等待超时完成,接下来您将做什么?只退出进程
  • Hmmmm... 超时时间后锁会被释放吗?那么 Process2 应该可以继续了吗?
  • 当然你可以在 mutex 上等待有限的时间,之后你可以继续运行。但互斥锁将由第一个挂起的线程拥有。所以在这种情况下,几个进程将同时运行,这是您想要避免的。互斥体,如果它的所有者挂起,当然永远不会被释放

标签: c++ visual-studio boost mutex boost-interprocess


【解决方案1】:

最后在 C# 中是 RAII 的程序仿真。由于自动存储变量在 C++ 中具有确定的生命周期(范围方面),因此只需在析构函数中进行解锁。

std 库类型为unique_lock; boost 也会有类似的。锁定互斥锁,并在销毁时解锁。

【讨论】:

  • 感谢您的回复。只是为了让我理解正确,unique_lock 的目的是保护互斥锁免受由于多个线程试图获取锁而导致的竞争条件?
  • @bks 不,它是 RAII 类型。唯一的意思是“打算在非共享模式下锁定互斥锁”。一些互斥锁(共享互斥锁)有两种锁定方法。如果你不知道什么 RAII 谷歌它并找到一些定义或教训。
猜你喜欢
  • 2013-09-29
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
  • 2022-01-21
  • 2021-06-21
相关资源
最近更新 更多