lkml.org 
[lkml]   [2002]   [Nov]   [8]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
SubjectRe: [Linux-ia64] reader-writer livelock problem
Date
In message <1036777105.13021.13.camel@ixodes.goop.org> you write:
> On Fri, 2002-11-08 at 09:25, Linus Torvalds wrote:
> > There's another reason for not doing it that way: allowing readers to keep
> > interrupts on even in the presense of interrupt uses of readers.
> >
> > If you do the "pending writes stop readers" approach, you get
> >
> > cpu1 cpu2
> >
> > read_lock() - get
> >
> > write_lock_irq() - pending
> >
> > irq happens
> > - read_lock() - deadlock
> >
> > and that means that you need to make readers protect against interrupts
> > even if the interrupts only read themselves.
>
> Even without interrupts that would be a bug. It isn't ever safe to
> attempt to retake a read lock if you already hold it, because you may
> deadlock with a pending writer. Fair multi-reader locks aren't
> recursive locks.

That's the point. This is explicitly guaranteed with the current
locks, and you are allowed to recurse on them. The netfilter code
explicitly uses this to retake the net brlock, since it gets called
from different paths.

Implement "read_lock_yield" or "wrlock_t" but don't break existing
semantics until 2.7 *please*!

Rusty.
--
Anyone who quotes me in their sig is an idiot. -- Rusty Russell.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

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