[linux-audio-dev] lock-free ring buffer code

Steve Harris S.W.Harris at ecs.soton.ac.uk
Sun Apr 6 11:40:59 UTC 2003

On Sun, Apr 06, 2003 at 01:10:17PM +0200, Ingo Oeser wrote:
> > Sure, it will only work on architectures where 32bit reads and writes are
> > atomic.
> That is not even true on all ix86 machines. At least I've seen
> special memory ordering barriers used in the kernel for newer
> ix86 machines.

I wasn't aware of that, do you have any pointers?
> > Smalled is not the issue, its branches that are important in inner loops.
> Right, but if your compiler unrolls your loop, uses indexes to
> load the data in a random order and increments your pointer later
> by a bigger chunk.
> e.g.
>   a1 = buffer[read_ptr++ & (size - 1)];
>   a2 = buffer[read_ptr++ & (size - 1)];
>   a3 = buffer[read_ptr++ & (size - 1)];
>   a4 = buffer[read_ptr++ & (size - 1)];
>   a5 = buffer[read_ptr++ & (size - 1)];
>   a_ = (a1 + a2 + a3 + a4 + a5) / 5;

Thats not a problem, it could be for writes, but I think it has to become
write then increment, not increment then write, cos of the use of foo++.
> It might be worth to code that all up to have a GPLed high
> performance fifo scheme. 

Probably, it should only be a smallish .h file.
> The glibc has internal support for atomic operations (at least
> atomic_add() is there and allows a negative argument, so
> atomic_sub() is there too and exchange_and_add(&lff->filled, 0)
> will provide an atomic read), so there is no problem about
> portability on Linux systems (and even other systems).

You should probably special case architectures where 32bit read/write is
atomic, as its a common case at the moment.

- Steve

More information about the Linux-audio-dev mailing list