From: Peter Dimov (pdimov_at_[hidden])
Date: 2008-04-21 14:10:19
>>> shared_mutex is not designed for this scenario, since you have high
>>> contention. shared_mutex is designed for infrequent updates.
Some more observations.
The same writer starvation occurs with 2 reader threads, so it's not caused
by the overcommit. Two reader threads on two cores is common.
The update frequency doesn't matter; a lower update frequency would just
scale the time it takes to perform 1M updates, it will not change the
average writer wait time.
Some wait times (2R+1W):
atomics: 7.673 microseconds
lightweight_mutex (CRITICAL_SECTION): 3.069 us
shared_mutex: 760 us
rw_mutex (my implementation): 665 us (same problem)
pthread_rwlock_t, pthreads-win32: 7.108 us
rw_mutex (Hinnant/Terekhov): 85.532 us
This last line uses my reimplementation of Howard Hinnant's read/write mutex
based on his description; Howard credits Alexander Terekhov with the
original algorithm. It does stall the writer a bit in exchange for optimal
reader throughput, but doesn't suffer from outright starvation.
I've attached my (not production quality) implementation of this rwlock.