boost::shared_mutex 1.50 中的问题

Question

各位 Boost 爱好者们好

我们遇到了 shared_mutex 的问题，并且一直在研究 boost 源。 我们无法判断这是否是一个死锁案例，或者我们只是不了解共享 读/写锁的互斥锁实现。

应用：

我们有一个地图map< Ptr*, data>，需要由多个线程创建和查询。 但是，大多数 Ptr* 值是常见的，因此会进行快速预热，然后 我们认为几乎没有插入到地图中的模式。所以我们想用 一个读/写模式来控制对地图的访问，像这样

boost::mutex& lock_;
bool found = false;
{
  shared_lock<boost::shared_mutex> slock(lock_);
  (search the map to see if you have key)
  if (keyFound) {
       found = true; 
  }
}
if (!found) {
   upgrade_lock<boost::shared_mutex> ulock(lock_);
   (search the map again to see if the key has been inserted)
   if (key still found) {
     upgrade_to_unique_lock<boost::shared_mutex> wlock(ulock);
     insert into the map & do whatever
  }
}

当块超出范围时应该销毁原始的shared_lock， 如果原始 shared_lock 不成功，则使 upgrade_lock 成为唯一的锁。

观察：

我们所有的线程都卡在了几天

_lll_lock_wait or pthread_mutex_lock

在深入研究 boost::shared_mutex 实现后，我们发现有 互斥锁内的单个通用“state_changed”锁，并且为了 shared_lock 或 unique_lock 成功，需要获取普通 state_changed 锁 用于锁的建造和破坏。似乎 unique_lock 将进入 它可能释放 state_changed 上的 scoped_lock 的状态，但我们无法确定。 无论哪种方式，我们都无法解释为什么线程基本上会长时间锁定 有零星的进展 - 这不是一个僵局，而是接近了。

任何帮助表示赞赏。

山姆阿普尔顿

Answer 1

查看Boost.Threadchange log，特别是问题#7755“线程：Windows 上的 shared_mutex 死锁”，该问题已在 1.54 中修复。这可能是您遇到的问题。

顺便说一句，自 1.50 以来已经修复了很多 Boost.Thread 错误，因此值得升级到最新版本。