Re: [PATCH 3/3] ring-buffer: add design document

[Steven Rostedt]

On Sun, 14 Jun 2009, Frederic Weisbecker wrote:
> > > > +
> > > > +Now the writer can update the head page. This is also why the head page must
> > > > +remain in UPDATE and only reset by the outer most writer. This prevents
> > > > +the reader from seeing the incorrect head page.
> > > > +
> > > > +
> > > > +(first writer)
> > > > +
> > > > +               A        B    tail page
> > > > +               |        |        |
> > > > +               v        v        v
> > > > +    +---+    +---+    +---+    +---+
> > > > +<---|   |--->|   |--->|   |--->|   |-H->
> > > > +--->|   |<---|   |<---|   |<---|   |<---
> > > > +    +---+    +---+    +---+    +---+
> > > 
> > > 
> > > Even more tricky!
> > > 
> > > I just have a stupid question: why can't this be done
> > > only through HEAD and NORMAL flags?
> > > 
> > > There is something certainly very obvious that I'm missing
> > > with the point of the UPDATE flag.
> > 
> > If you can demonstrate how to do the above lockless with just HEAD and 
> > NORMAL, then sure, I'm all ears ;-)
> > 
> > When we switch the HEAD to UPDATE, we stop the reader from moving forward 
> > and being another thing to handle while we move the HEAD forward. A reader 
> > does a cmpxchg to move the head too, and that cmpxchg will always fail if 
> > the pointer is has UPDATE set. The reader will just spin until it 
> > succeeds.
> 
> 
> Aah, so it's here to protect against paralell readers from another cpu
> reading the current cpu buffer, right?

Not readers, but reader. The reader side uses locks to serialize the
accesses. The writer side is lockless.  But it is here to protect the 
writers against a reader on another CPU.

-- Steve


> 
> 
> > Then, the rest of the moving of the header is just races with other 
> > writers that are always on the same CPU, and it becomes a recursive 
> > problem and not a parallel one.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/