在Linux上,boost :: shared_mutex比粗略的std :: mutex慢

Question

我有一个std::unordered_map来自多个线程的非常繁重的工作负载.我可以使用a std::mutex进行同步,但由于并发读取应该没问题,我想用一个boost::shared_mutex代替.为了测试性能改进,我首先使用一堆值预先填充一个映射,然后让一堆线程运行读取测试:

for (int i = 0; i < iters; ++i) map.count(random_uint(0, key_max));

我跑这对我的粗锁的实现,其中count被保护std::lock_guard<std::mutex>和我共享锁实现在那里被保护boost::shared_lock<boost::shared_mutex>.

在我的带有GCC 6.1.1的Arch Linux x86_64系统上,boost::shared_lock版本总是更慢!在我的朋友与MSVC 2013的Windows 10系统中,boost::shared_lock是永远快! 完整的,可编译的代码在github上:https://github.com/silverhammermba/sanity

编辑

这似乎是一个特定于平台的问题.往上看.我真的很感激,如果其他人可以构建和运行此代码并报告他们是否看到正输出(shared_lock更快)或负面(当前互斥更快)以及您正在使用的平台.

Answer 1

事实证明,这在Linux上boost::shared_mutex是"次优的".

boost :: shared_mutex对'pthread'的当前(作为boost 1.59)实现是非常不理想的,因为它使用重量级互斥锁来保护内部互斥锁状态...... [当访问并发性很高时]共享互斥锁实际上是独占的.

为了提升和我生命中的许多小时,它已经被盗了.