C++14 shared_timed_mutex VS C++11 互斥量

Question

我有一个在 8 个线程之间共享的哈希表(我有一个 8 核 PC)，每个线程在哈希表中读取和写入。

在示例 1 中，我使用了经典的互斥锁，所有 8 个核心都处于 100%在示例 2 中，我使用了 shared_timed_mutex，因为读取访问可以竞争，但所有 8 个核心都在 40%

问题出在哪里？

example 1:
mutex mutex_hash;

-- thread --
mutex_hash.lock();
//read
mutex_hash.unlock();
..
mutex_hash.lock();
//write
mutex_hash.unlock();

============================

example 2:
shared_timed_mutex mutex_hash;

-- thread --
mutex_hash.lock_shared();
//read
mutex_hash.unlock_shared();
..
mutex_hash.lock();
//write
mutex_hash.unlock();

Answer 1

由于您的问题有些含糊，而且除了您之外，任何人都无法重现该行为，因此我只能猜测。

我最好的猜测是:

shared_timed_mutex 并不总是比 mutex 好。如果是，就不需要 mutex。我们只需摆脱 mutex，将 shared_timed_mutex 重命名为 mutex，从此过上幸福的生活。不幸的是，现实生活比这更复杂。

有时 mutex 是更好的工具。有时 shared_timed_mutex 是更好的工具。

例如:如果我们有8个线程在争夺互斥锁，每个线程有50%的概率需要读或写，并且读写任务需要持有互斥锁的时间大致相同，那么有使用 shared_timed_mutex 类型没什么好处。

要理解这一点，请考虑所有 8 个线程同时请求 shared_timed_mutex 的场景。如果一个 writer 先得到它(50% 的概率)，那么所有 7 个其他线程都会阻塞(就像我们使用 mutex 一样)。

在另外 50% 的时间里，读者首先得到它。第二个请求锁的线程有 50/50 的机会成为读者。如果是写者，公平的实现会阻止剩余的读者获取锁。这种情况发生的概率为 0.5 * 0.5 == 25%。所以现在我们最多有 75% 的时间，一次只能运行一个线程:{W, block...} 和 {R, W, block...}。

25% 的时间我们得到 {R, R, ?...}，其中至少有两个线程可以同时运行。

好吧，至少 25% 的人同时运行两个或更多线程是不是值得的？

视情况而定。

mutex 比 shared_timed_mutex 简单。更简单的代码导致更快的代码。

shared_timed_mutex 当读者的数量远远超过作者，并且当读者的任务比作者的任务长和/或常见时，它会发光。

例如，如果您有一个数据库，除了每年更新 6 次(更新需要 1 秒)之外保持不变，那么使用 shared_timed_mutex 读取该数据库就很有意义锁定在共享模式。人们可以很容易地负担得起每两个月以唯一模式将其锁定一秒钟。

但如果您尝试每秒更新该数据库，情况就完全不同了，shared_timed_mutex 可能根本不会为您提供任何性能优势。在这种情况下，仅要求每个人(读者和作者)请求独占访问可能会更便宜(因为逻辑更简单)。