Does Multiple reader single writer implementation in g++-4.4(Not in C++11/14) via boost::shared_mutex impact performance?

Question

Usage: In our production we have around 100 thread which can access the cache we are trying to implement. If cache is missed then information will be fetched from the database and cache will be updated via writer thread.

To achieve this we are planning to implement multiple read and single writer We cannot update the g++ version since we are using g++-4.4

Update: Each worker thread can work for both read and write. If cache is missed then information is cached from the DB.

Problem Statement: We need to implement the cache to enhance the performance. For this, cache read are more frequent and write operations to the cache is very much less.

I think we can use boost::shared_mutex boost::shared_lock, boost::upgrade_lock, boost::upgrade_to_unique_lock implementation

But we learnt that boost::shared_mutex has performance issues:

• Performance comparison on reader writer locks
• Lib boost devel

Questions

1. Does boost::shared_mutex impact the performance in case read are much frequent?
2. What are other constructs and design approaches we can take while considering compiler version g++4.4?
3. Is there a way-around on how to design it, such that reads are lock free?

Also, we are intended to use Map to keep the information for cache.

Answer 1

If writes were non-existent, one possibility can be 2-level cache where you first have a thread-local cache, and then the normal cache with mutex or reader/writer lock.

If writes are extremely rare, you can do the same. But have some lock-free way of invalidating the thread-local cache, e.g. an atomic int updated with every write, and in those cases clear the thread-local cache.

Answer 2

You need to profile it.

In case you're stuck because you don't have a "similar enough" environment where you can actually test things, you can probably write a simple wrapper using pthreads: pthread_rwlock_t

• pthread_rwlock_rdlock
• pthread_rwlock_wrlock
• pthread_rwlock_unlock

Of course you can design things to be lock free. Most obvious solution would be to not share state. (If you do share state, you'll have to check that your target platform supports atomic instructions). However, without any knowledge of your application domain, I feel very safe suggesting you do not want lock-free. See e.g. Do lock-free algorithms really perform better than their lock-full counterparts?