Actually, his
implementation is similar to ringbuffer.c in
libjack... and assumes that reading and writing can happen
atomically (as was pointed out by someone else) -- which can
be managed with single reader / single writer
requirement.[a]
Unless I've misunderstood the code, ringbuffer.c is /not/
using special atomic operations.
Why should a single-reader-single-writer ring-buffer need atomic operations?
The reader increments the read-pointer (which doesn't have to be a pointer)
last when its finished,
how do you ensure, that the read pointer is incremented _after_ the data
has been written to the output?
the writer increments the write-pointer last when it
has written.
likewise, how do you ensure, that the write pointer is incremented
_after_ the data has been written to the ringbuffer?
also, when reading the read/write pointers, you need to ensure, that
they are loaded, before you touch the ringbuffer.
All other access is read-only. No problems. (At least
in my app.)
your code may work on x86, not necessarily on ppc, ia64 ... and then
there is alpha ...
we are not in a world, where assembler instructions are executed one
after the other, but we have out-of-order cpus with speculation and
multi-processor systems with non-shared caches ...
hth, tim
--
tim(a)klingt.org
http://tim.klingt.org
Which is more musical, a truck passing by a factory or a truck passing
by a music school?
John Cage