On Fri, 2008-10-17 at 08:56 -0400, Paul Coccoli wrote: > Why do you suspect you need memory barriers? My concern with > ringbuffer.c is the non-atomic ops on the read and write pointers. > They're marked volatile, but what I think you really want is make all > ops on those fields atomic. Stuff like this: > > rb->read_ptr += n1; > rb->read_ptr &= rb->size_mask; > > Looks like a problem to me. What happens if there's a context switch > in between those 2 statements? this is the core of the "idea" of the thread-safe ringbuffer. step back. answer the question. what *does* happen? it means that the read_ptr has an unnecessarily high value, which means that we *under*-estimate the space available for writing.. ditto for the write_ptr case, where we *under*-estimate the data available for reading. we can and *do* anticipate that context switches will occur there - there is no general way to that execute that operation (increment-and-mask) in a lock-free atomic way. the idea is that even if it does happen, the resulting error prevents the buffer from being misused. of course, its a little inefficient. but until we get cpu's with atomic inc-and-mask instructions, its the price we pay for going lock-free (and its a relatively small cost). --p _______________________________________________ Linux-audio-user mailing list Linux-audio-user@xxxxxxxxxxxxxxxxxxxx http://lists.linuxaudio.org/mailman/listinfo/linux-audio-user
