c++ - 1.50 中的 boost::shared_mutex 问题

Question

嗨，Boost 爱好者们

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

应用:

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

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
  }
}

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

观察:

我们所有的线程都在

_lll_lock_wait or pthread_mutex_lock

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

感谢任何帮助。

山姆·阿普尔顿

Answer 1

看看 Boost.Thread change log ，特别是问题#7755“线程:在 Windows 上使用 shared_mutex 死锁”，已在 1.54 中修复。这可能是您遇到的问题。

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