Question

嗨同胞助推爱好者

我们遇到了shared_mutex的问题，并且一直在深入研究增强源。我们无法判断这是否是一个僵局，或者我们只是不了解共享读写器锁的互斥实现。

申请：

我们有一个地图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实现时，我们发现存在一个共同的＆＃34; state_changed＆＃34;锁定在互斥锁内，并为了任何一个要成功shared_lock或unique_lock，它需要获取公共state_changed锁锁定构造和破坏。看来unique_lock会进入一个状态，可能在state_changed上释放scoped_lock，但我们无法分辨。无论哪种方式，我们都无法分辨为什么线程基本上会锁定很长一段时间随着零星的进步 - 它并不是一个僵局，而是一些接近的东西。

任何帮助表示感谢。

Sam Appleton

Answer 1

请查看Boost.Thread change log，特别是问题＃7755“线程：Windows上的shared_mutex死锁”，已在1.54中修复。这可能是你遇到的问题。

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

1.50中的boost :: shared_mutex问题

1 个答案: