Re: furwocks: Fast Userspace Read/Write Locks

[Hubertus Franke <frankeh@watson.ibm.com>]

On Friday 08 March 2002 11:50 pm, Rusty Russell wrote:
> In message <3C888284.8030206@loewe-komp.de> you write:
> > Rusty Russell wrote:
> > > To clarify: I'd love this, but rwlocks in the kernel aren't even
> > > vaguely fair.  With a steady stream of overlapping readers, a writer
> > > will never get the lock.
> > >
> > > Hope that clarifies,
> >
> > But you talk about the current implementation, don't you?
> > Is there something to prevent an implementation of rwlocks in the
> > kernel, where a wrlock will lock (postponed) further rdlock requests?
>
> It's proven hard to do without performance impact.  Also, we can't do
> rw semaphores in a single word: you need two.
>
> Disproving me by implementation VERY welcome!
>
> Hope that helps,
> Rusty.

Well I did it with one word and cmpxchg and two queues in the kernel.
The two queues can be consolidated to one if the wait_element for the
queue has a third word, namely read or write.

Did you have a chance to think about the 
FUTEX_UP and FUTEX_UP_FAIR issue.
This should be simple enough as shown in the patch that pulled
your two approaches together. It doesn't seem to come at an
additional cost for the simple FUTEX_UP case.

I thought about it some more and talked to some other folks here.
One option is to wake up multiple ones as well to avoid starvation
and increase throughput.
E.g.    FUTEX_UP_SOME where you wake up #cpu tasks.
They would then go and contend for the lock again.

 
-- 
-- Hubertus Franke  (frankeh@watson.ibm.com)