On Wed, 13 Nov 2002, Paul Davis wrote: >>my conclusion is that the level of atomicity provided by >>linux asm-arch/atomic.h is not needed to implement >>single-reader-single-writer lock-free buffers. > this is true unless the pointer/index isn't atomic. since on SMP sparc > systems, the arrangement of the cache lines means that you can't > guarantee better than 24 bit atomic values, you do have to be careful > about the potential size and memory position of the pointer/index > variables.
I've browsed through the sparc arch manuals and couldn't find anything that would limit atomic access to 24 bits nor any directly related cache line limitations. The Linux asm-sparc/atomic.h provides only 24bits as it uses the lower 8bits to implement a low-overhead spinlock. Spinlock is required to guarantee memory ordering (also with mixed usage of various atomic_* ops). If you just read/write 32bit ints, this is atomic even on SMP-sparcs. >>in handling the l-f buffer indices. In the worst case >>reported write-space is larger, or read-space smaller, >>than the actual situation. > actually, the worst case for both metrics is that they are *smaller* > than they should be. this happens on two occasions: Ugh, true, my mistake. > its not so much "atomicity" as "ordered" that is needed here. because > read/write will only use that part of the buffer indicated as > available by the r/w pointers, all we have to know is that the writes > to the buffer complete before the write pointer is updated. it would > be good to use a so-called "memory barrier" somewhere there to make > sure this is true. Ok, this is a real problem, but I don't think using asm-arch/atomic.h (which can guarantee ordered access to the buffer indices) helps to solve this issue, so you might just as well use regular ints as the atomic indices. And this really is a corner case as the buffer would have to be close to empty (something has already gone wrong!) to read old data from the buffer, even on a SMP sparc or s390. -- http://www.eca.cx Audio software for Linux!
