Boost logo

Boost :

From: Howard Hinnant (hinnant_at_[hidden])
Date: 2008-04-21 16:04:41

On Apr 21, 2008, at 2:10 PM, Peter Dimov wrote:
>>>> 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.
> <rw_mutex.hpp>_______________________________________________
> Unsubscribe & other changes:

I've so far only looked at your implementation for a few minutes. The
lock-reduced version is tricky. It has been three years since I did
this, but when I did, I needed 3 flags instead of your two. That may
have been because I was guarding against max-readers and you're not,
not sure yet. When I wrote it, it was on ppc only and so used the
lwarx/stwcx. instructions directly and so was not written in a compare/
exchange style.

It might be interesting to run this
  through your test. It is the algorithm, but not "lock reduced".


Boost list run by bdawes at, gregod at, cpdaniel at, john at