[lkml]   [2000]   [Sep]   [12]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: [patch]2.4.0-test6 "spinlock" preemption patch
Rik van Riel wrote:
> On Tue, 12 Sep 2000, Andrea Arcangeli wrote:
> > On Wed, 6 Sep 2000, George Anzinger wrote:
> >
> > >The times a kernel is not preemptable under this patch are:
> > >
> > >While handling interrupts.
> > >While doing "bottom half" processing.
> > >While holding a spinlock, writelock or readlock.
> > >
> > >At all other times the algorithm allows preemption.
> >
> > So it can deadlock if somebody is doing:
> >
> > while (test_and_set_bit(0, &something)) {
> > /* critical section */
> > mb();
> > clear_bit(0, &something);
> > }
> > The above construct it's discouraged of course when you can do
> > the same thing with a spinlock but some place is doing that.
> Hmmm, maybe the Montavista people can volunteer to clean
> up all those places in the kernel code? ;)
> cheers,

Well, I think that is what we are saying. We are trying to understand
the lay of the land and which way the wind is blowing so that our work
is accepted into the kernel. Thus, for example, even now both
preemption and rtsched are configuration options that, when not chosen,
give you back the same old kernel (with possibly a more readable debug
option in spinlock.h and a more reliable exit from entry.S :)

Along these lines, we do want to thank Andrea for pointing out this code
to us. It is always better to have someone point out the tar pits prior
to our trying to walk across them (and verily, he was never seen again

To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
Please read the FAQ at

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