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

Question

我有一个8个线程之间的共享哈希表(我是一个8核PC),每个线程在哈希表中读写.

在示例1中,我使用了经典的互斥锁,并且在示例2中所有8个核心都是100%我使用了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类型.

要理解这一点,请考虑shared_timed_mutex同时请求所有8个线程的场景.在编写器首先获得它(50%概率)的情况下,所有其他7个线程都阻塞(就像我们使用a一样mutex).

在另外50%的时间里,读者首先得到它.请求锁定的第二个线程有50/50的机会成为读者.如果是作家,公平的实施将阻止其余的读者获得锁定.这发生在0.5*0.5 == 25%的时间.所以现在我们高达75%的时间,一次只能运行一个线程:{W,阻止...}和{R,W,阻止...}.

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

好吧,至少不是25%得到两个,也许更多的线程一次运行值得吗？

这取决于.

mutex比...更简单shared_timed_mutex.更简单的代码可以实现更快的代码.

shared_timed_mutex 当读者远远超过作者时,以及读者任务与作家任务相比较长和/或普遍时,会发光.

例如,如果您有一个数据库,除了每年更新6次(并且需要1秒更新)之外,它仍然是不可变的,因此在shared_timed_mutex锁定共享模式下读取该数据库非常有意义.人们可以轻松地以独特模式每两个月锁定一次.

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