Boost logo

Boost :

From: Peter Dimov (pdimov_at_[hidden])
Date: 2008-04-21 10:37:18

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

> 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".

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