C++14 shared_timed_mutex VS C++11 mutex

Question

I've an shared hash table between 8 threads (i've an 8 core PC), each thread reads and writes in the hash table.

in example 1 i used classic mutex and all 8 core are at 100% in example 2 i used shared_timed_mutex because read access can be in competition but all 8 core are at 40%

Where is the problem?

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

Since your question is somewhat vague and the behavior is not reproducible by anyone aside from yourself, I can only guess.

My best guess is:

shared_timed_mutex is not always better than mutex. If it were, there would be no need for mutex. We would just get rid mutex, rename shared_timed_mutex to mutex, and live happily ever after. Unfortunately real life is more complicated than that.

Sometimes mutex is the superior tool. Sometimes shared_timed_mutex is the superior tool.

For example: If we have 8 threads contending for the mutex, and each thread has a 50% probability of needing to read or write, and the read and write tasks require holding the mutex approximately the same amount of time, then there is little gain in using a shared_timed_mutex type.

To understand this, consider the scenario of all 8 threads requesting the shared_timed_mutex at the same time. In the case a writer gets it first (50% probability), then all 7 of the other threads block (same as if we were using a mutex).

In the other 50% of the time a reader gets it first. The second thread to request a lock has a 50/50 chance of being a reader. If it is a writer, a fair implementation will block the remaining readers from acquiring the lock. This happens 0.5 * 0.5 == 25% of the time. So now we're up to 75% of the time, only one thread can run at a time: {W, block...} and {R, W, block...}.

25% of the time we get a {R, R, ?...}, where at least two threads can run at the same time.

Well, at least isn't 25% getting two and perhaps more threads running at once worth it?

It depends.

mutex is simpler than shared_timed_mutex. Simpler code leads to faster code.

shared_timed_mutex shines when the readers far outnumber the writers, and when the reader-task is long and/or common compared to the writer-task.

For example if you have a database that remains immutable except for being updated 6 times a year (and takes 1 second to update), it makes a lot of sense to read that database with a shared_timed_mutex locked in shared mode. One can easily afford to lock it for a second once every two months in unique mode.

But if you are trying to update that database every second, this is a completely different situation, and shared_timed_mutex may not offer you any performance advantage at all. In this case it may be cheaper just to require everyone (reader and writer) to ask for exclusive access (because the logic is simpler).