BOOST：递归shared_mutex？

似乎Boost的shared_mutex是非递归的。有没有反正呢？（无需重新执行整个内容）BOOST：递归shared_mutex？

来源

2010-07-22 GabiMe

在走下这条道路之前，您可能需要阅读关于递归互斥体的[别人认为]（http://www.zaval.org/resources/library/butenhof1.html）。 – 2010-07-22 13:03:42

你看过boost：recursive_mutex吗？ – 2010-07-22 15:22:45

是的，但不共享 – GabiMe 2010-07-24 23:13:29

-3

在这些情况下，您必须使用shared_ptr。把你的互斥量放在一个shared_ptr中，它会对你的互斥量进行计数，这会给你带来相似的结果。

来源

2010-07-22 13:14:32 Gianni

boost :: weak_ptr与boost :: shared_mutex有什么关系？ – 2010-07-22 15:21:09

@Sam抱歉，我想到了一些东西，并完全写了一个。我编辑了我的帖子，使其更清晰/更正。 – Gianni 2010-07-22 15:30:09

'shared_ptr'与这个问题无关。问题不在于共享物理对象（哪个'shared_ptr'允许），而是共享和索引锁的拥有权（同步概念而不是C++对象）。 – 2011-01-03 10:10:26

boost :: recursive mutex是排他性的。我想你需要扩展shared_mutex。您可以将当前线程ID保存在一个集合中，并检查它是否存在于提供锁定的函数集合中。

来源

2011-01-14 06:04:16 apoorvkul

我以前一直在走这条路。简单的答案是否定的，没有shared_recursive_mutex。

我并不完全同意其他人会告诉你递归互斥体如何通常是一个坏主意，它肯定可以节省一些时间并避免一些错误。但是，如果你不想实现你自己的shared_recursive_mutex，你必须坚持使用非递归互斥体。也不是那么坏。

来源

2011-01-14 17:48:11

看一看this thread和这excellent explanation为什么shared_mutex是一般的坏主意。所以如果你不同意recursive_mutex也是不好的想法，只需使用它而不需要任何潇洒因为它不能给你任何性能提升。你将会得到更清洁的代码而不会有任何重大改变。

我试图在我的项目中使用shared_mutex来锁定高度争用的地图，当很多线程经常读取数据并且很少修改它时。收到了更差的性能结果

来源

2011-02-02 12:22:28

是的。确实非常有趣的分析。谢谢！ – GabiMe 2011-02-02 21:02:08

我部分不同意安迪，shared_mutex是一个坏主意，因为它取决于您的设计，即如何在程序中使用它。我相信，如果你使用共享互斥锁进行长时间的频繁读取，它可以为你带来更高效的性能，比如果你使用简单的互斥锁来简化更频繁的读取罕见着作的锁定。所以shared_mutex是一种同时做很长时间的方法。而且我不认为在这种情况下长锁是不好的设计。

你支持我还是我错了？

来源

2013-01-15 09:55:20

BOOST：递归shared_mutex？

回答

相关问题