Re: [boost] shared_mutex deadlocks?

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