6 Apr
2003
6 Apr
'03
1:40 p.m.
On Sun, Apr 06, 2003 at 01:10:17PM +0200, Ingo Oeser wrote:
I wasn't aware of that, do you have any pointers?
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++.
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. 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; 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