通过boost :: shared_mutex对g ++ - 4.4(不是C++ 11/14)中的多个读者单一编写器实现会影响性能吗？

Question

用法:在我们的生产中,我们有大约100个线程,可以访问我们试图实现的缓存.如果错过了缓存,则将从数据库中获取信息,并且将通过编写器线程更新缓存.

为此,我们计划实现multiple read and single writer我们无法更新g ++版本,因为我们正在使用g++-4.4

更新:每个工作线程都可以用于读取和写入.如果错过了缓存,则从DB缓存信息.

问题陈述: 我们需要实现缓存以提高性能.为此,缓存读取更频繁,对缓存的写入操作非常少.

我觉得可以用boost::shared_mutex boost::shared_lock,boost::upgrade_lock,boost::upgrade_to_unique_lock implementation

但我们了解到boost::shared_mutex存在性能问题:

• 读写器锁的性能比较
• Lib加速发展

问题

1. boost::shared_mutex在读取的情况下是否会影响性能？
2. 在考虑编译器版本时,我们可以采取哪些其他构造和设计方法g++4.4？
3. 有没有解决方法如何设计呢reads are lock free？

此外,我们还打算用来Map保存缓存信息.

Answer 1

如果写入不存在，一种可能性可能是2-level cache您首先有 a thread-local cache，然后是normal cache with mutex or reader/writer lock.

如果写入极其罕见，您也可以这样做。但是有一些无锁的方法可以使线程本地缓存失效，例如每次写入都会更新原子 int ，并且在这些情况下清除线程本地缓存。