Re: PATCH: kernel-2.4 brlock livelock

[linas@austin.ibm.com]

On Thu, Sep 04, 2003 at 05:44:02AM +1000, Anton Blanchard wrote:
> 
> Hi,
> 
> > The patch changes the non-atomic code. It grabs the write lock, and
> > then spins, waiting for all of the existing readers to finish. 
> > New readers are held off.  This seems (to me) to be a reasonable 
> > thing to do, based on the following logic:
> 
> The problem is with recursive readers. One cpu takes a br read lock then
> wants to take the same lock again. It must be allowed to get that read lock.
> 
> We need to drop the write spinlock or else we will deadlock.

Whoops. 

OK, how about the following: readers on a given cpu are held off 
if the write lock is held *and* the read-count on that cpu is zero?

That way, 'recursive' readers on other CPU's can get a read-lock if
there's already a non-zero read-lock-count on that CPU.   

That should work if the thread holding the lock can't get scheduled
to another cpu.  Can these things wander around?

If they can wander around, then oone would have to order the cpus:
wait for read count to drop to zero on cpu 0 then on 1 then on 2, 
meanwhile the read-lock can be gotten on the higher ordered CPUs ...

If this sounds reasonable, would you care to see a revised patch?

What else can go wrong?

--linas