lkml.org 
[lkml]   [1999]   [Aug]   [21]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
SubjectRe: [PATCH] i386 rwlock bug?
Date
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/

\
 
 \ /
  Last update: 2005-03-22 13:53    [W:0.025 / U:0.204 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site