rwlocks, correctness over speed.

[Attilio Rao]

2007/11/22, dima <_pppp at mail.ru>:
> > In summary, I am proposing (temporarily) making read-recursion
> > on rwlocks not supported in order to avoid livelock due to writer
> > starvation.
>
> It's not the matter of recursion, but the implementation itself.
> Comments from the code:
> <quote>
>          * Note that we don't make any attempt to try to block read
>          * locks once a writer has blocked on the lock.  The reason is
>          * that we currently allow for read locks to recurse and we
>          * don't keep track of all the holders of read locks.  Thus, if
>          * we were to block readers once a writer blocked and a reader
>          * tried to recurse on their reader lock after a writer had
>          * blocked we would end up in a deadlock since the reader would
>          * be blocked on the writer, and the writer would be blocked
>          * waiting for the reader to release its original read lock.
> </quote>
> Such a design would provide writer starvation regardless the presence of recursion. If a writer is waiting for the lock, no more readers should be allowed. It's a simple rule to avoid writer starvation in rw-locks. Recursion does need an accurate accounting of all the current readers.
> I've posted a reference implementation of rw-locks to this mailing list about a year ago. My proposal was to use an array to account the current readers (the array can be handled without any additional locking). It limits the maximum read contention, though.

The real problem with this is that currently we have a fast path which
is only an atomic add. What you propose will make the fast path too
slow (not mentioning the limitation), and this is somethign we should
avoid if possible.

Attilio


-- 
Peace can only be achieved by understanding - A. Einstein