15

似乎 Boost 的 shared_mutex 是非递归的.. 反正有这个吗?(没有重新实现整个东西)

4

5 回答 5

8

看看这个线程和这个很好的解释为什么shared_mutex一般来说是个坏主意。因此,如果您不同意这recursive_mutex也是一个坏主意,请在没有任何共享的情况下使用它,因为它不能给您带来任何性能提升。您将收到更简洁的代码,无需任何重大更改。

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

于 2011-02-02T12:22:28.330 回答
1

我部分不同意 Andy 认为 shared_mutex 是一个坏主意,因为它取决于您的设计,即您如何在程序中使用它。我相信,如果您使用共享互斥锁进行长时间频繁的读取,它可以为您带来更高效的性能,而不是使用简单的互斥锁来进行更短的更频繁的锁定以读取稀有的作品。所以 shared_mutex 是一种长时间同时做某事的方法。而且我不认为在这种情况下长锁是一个糟糕的设计。

你支持我还是我错了?

于 2013-01-15T09:55:20.980 回答
1

我以前亲自走过这条路。简单的答案是否定的,没有 shared_recursive_mutex。

我不太同意其他人会告诉你递归互斥锁通常是一个坏主意,它当然可以节省一些时间并防止一些错误。但是,如果您不想实现自己的 shared_recursive_mutex,则必须坚持使用非递归互斥锁。也不是那么坏。

于 2011-01-14T17:48:11.707 回答
0

boost::recursive mutex 是独占的。我认为您将需要扩展 shared_mutex。您可以将当前线程 ID 保存在一个集合中,并在提供锁的函数中检查它是否存在于集合中。

于 2011-01-14T06:04:16.697 回答
-3

在这些情况下,您必须使用shared_ptr 。将您的互斥锁放在 shared_ptr 中,它会对您的互斥锁进行引用计数,这将为您提供类似的结果。

于 2010-07-22T13:14:32.610 回答