Messages in this thread | | | From | "Lennert Buytenhek" <> | Subject | Re: [PATCH] i386 rwlock bug? | Date | Sat, 21 Aug 1999 10:55:16 +0200 |
| |
Hi,
>> Bug or feature? >> I've modified this to leave the high bit on while waiting for the >> readers to go away, thus making the high bit a 'write lock pending' >> bit. This makes sure that while the writer is waiting for the write >> lock no more readers can come in.
>I think this is a feature: >rw-locks can be use partially in interrupts: >* write only from outside interrupts >* read from everywhere
And they still can with my patch.
>if a writer spins (interupts are enabled), then an interrupt occurs, >then you have a dead-lock.
You're being a bit vague here, but I take this as follows: If trying to acquire a write lock locks out more readers and an interrupts tries to acquire a read lock the machine can hang.
This is a non-argument. I thing you should go back and read Documentation/spinlocks.txt (or whatever). If interrupts can acquire a rwlock in read mode a write lock _must_always_ lock out irqs, whether you use my patch or not. Go read the file. It's in there.
If a read_lock sees that the high bit is set it will spin. The fact that my patch leaves the high bit on is just a 'hey, somebody wants to get in here.' It makes no difference to readers whether a writer has really acquired the lock (i.e. 0 readers) or whether a writer is waiting for the readers to go away, since in both cases the high bit is set. Readers don't see the difference.
>add your code as a "rw-don't-starve-lock", but I think the normal >rw_lock must starve writers.
Why then? It does not deadlock any more than with the ordinary behaviour.
Greetings, Lennert
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.tux.org/lkml/
| |