1.50中的boost :: shared_mutex问题

Question

嗨，各位资深爱好者

我们遇到了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.Thread 更改日志 ，尤其是问题＃7755“线程：Windows上具有shared_mutex的死锁”，该问题已在1.54中修复。 这可能是您遇到的问题。

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