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
