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.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk