【问题标题】:Prevent deadlock shared boost mutex防止死锁共享boost互斥锁
【发布时间】:2012-01-21 05:26:33
【问题描述】:

我想使用共享互斥锁,因此只有在写入而不是读取向量/映射/任何内容时,线程才会被锁定。但我认为 func2() 永远不会获得唯一锁,因为 func1() 永远不会解锁。尝试获取唯一锁时,有什么方法可以不计算 shared_mutex 上的同线程锁?或者即使那样问题仍然存在?

我猜我需要找到一种方法在所有线程都达到 func2() 或释放锁后强制获取锁(一次一个线程)。

func2()
{
    boost::unique_lock<boost::shared_mutex> lock_access3(shared_mutex);
    /*stuff*/
    lock_access3.unlock(); 
}

func1()
{
    boost::shared_lock<boost::shared_mutex> lock_access1(shared_mutex);
    func2();
    lock_access1.unlock();
}

【问题讨论】:

    标签: c++


    【解决方案1】:

    我相信您需要使用递归互斥锁。请参阅关于这个问题的精彩讨论:

    Boost 在 boost:recursive_mutex 类中提供此功能。

    【讨论】:

    • 这对他没有帮助,因为他需要读/写(共享/独占)锁。
    【解决方案2】:

    你需要做的两件事:

    1)由于func1实现了写操作,所以需要获取排他锁,而不是共享锁。

    2) 由于调用func2 时已持有锁,因此不应尝试获取锁。

    【讨论】:

    • func1 读取。阅读后,它可能会或可能不会调用将写入的 func2()。对互斥锁(以及一般的 c++)来说仍然是新手,也许解决方案真的很简单。我只是没看到。
    • 所以func1 实现了一个写操作(“可能写”操作是一种写操作。)它通过调用func2 来实现它是无关紧要的。执行写操作的函数必须获得排他锁。
    • 如果 func1 非常长怎么办?如果它不打算改变我试图保护免受损坏的向量/映射/堆,那么其他线程等待它完成是没有意义的。
    • 您有三个选择: 1) 您可以持有独占锁,看看性能影响是否显着。 2) 您可以使用可升级锁。 (这可能没有您期望的那么大。) 3)您可以使用解锁并重新开始算法。 (获取读锁,尝试操作,在不太可能的情况下需要写,释放读锁,获取写锁,重新开始——如果仍然需要写,你很好,因为你仍然持有写锁)。
    猜你喜欢
    • 1970-01-01
    • 2011-07-22
    • 1970-01-01
    • 2023-03-09
    • 2015-10-26
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    相关资源
    最近更新 更多