Anthony Williams:
Here's the thing: your writer is running in a tight loop, and so are your readers, with each reacquiring the lock immediately after releasing it.
Right. This emulates a server that needs to service many concurrent reader requests. I don't have time to make it more real; the USE_RWLOCK path is for comparison purposes only.
shared_mutex is not designed for this scenario, since you have high contention. shared_mutex is designed for infrequent updates.
I don't believe that the behavior I'm seeing matches the intent of the design.
In the current implementation, a blocked writer will prevent further readers acquiring the lock, thus if you frequently try and obtain a writer lock this reduces the potential reader concurrency. However, in order to avoid reader starvation, the writer is not automatically granted the lock when the read lock is released: instead it has to compete for the privilege with the blocked readers. It is up to the OS how it chooses to schedule it.
In theory, given 7 readers and one writer competing for the lock, the writer should get the lock 1/8 of the time, leading to an 8x reader:writer iteration ratio. But it doesn't. I still suspect there's something wrong with the lock that unintentionally favors readers. One possible explanation is that the reader thread that just released the lock is able to obtain it again. This should never happen if there's a writer waiting; the reader should be blocked "on the first gate".