Messages in this thread | | | Date | Fri, 1 May 2009 19:42:28 +0200 | From | Ingo Molnar <> | Subject | Re: [PATCH 3/3] ring-buffer: make cpu buffer entries counter atomic |
| |
* Steven Rostedt <rostedt@goodmis.org> wrote:
> > On Fri, 1 May 2009, Ingo Molnar wrote: > > > > > * Steven Rostedt <rostedt@goodmis.org> wrote: > > > > > On Fri, 1 May 2009, Ingo Molnar wrote: > > > > > The entries keeps track of the number of entries in the buffer. A > > > > > writer (producer) adds to the counter and readers (consumers) > > > > > subtract from them. A writer can subtract them if it overwrites a > > > > > page before the producer consumes it. > > > > > > > > > > Only the writers are pinned to a CPU, the readers happen on any > > > > > CPU. > > > > > > > > But that does not require atomicity. It requires careful use of > > > > barriers, but otherwise atomicity is not needed. Update of machine > > > > word variables (if they are aligned to a machine word) is guaranteed > > > > to be atomic, even without atomic_t overhead. > > > > > > I'm confused :-/ This throws out all that I learned in multi threaded > > > programming. > > > > > > If I have a shared variable used by two threads, the adding and > > > subtracting of that variable does not need to be atomic? > > > > > > CPU0 CPU1 > > > ---- ---- > > > load A load A > > > sub 1, A sub 1, A > > > store A store A > > > > > > can work?? > > > > no, that wont work. But as long as there's just a single CPU that is > > a _writer_ (does stores), it can be observed in an atomic/coherent > > manner, without the use of atomics. > > Ah, maybe there's confusion in my explanation. When I talk about > writers and readers, I'm talking about those writers into the ring > buffer and readers from the ring buffer. But both writers and > readers write to the entries counter. Readers subtract and writers > add. But writers can also subtract on overruns.
a solution for that would be to split it into two counts - for both sides. Or to eliminate it if possible. We _really_ need to make the ring-buffer _much_ cheaper than it is today. y Ingo
| |