Subject: Re: [linux-audio-dev] lock-free ring buffer code
From: Steve Harris (S.W.Harris_AT_ecs.soton.ac.uk)
Date: Sun Apr 06 2003 - 18:30:59 EEST
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
This archive was generated by hypermail 2b28 : Sun Apr 06 2003 - 18:25:24 EEST