On 11 July 2011 21:32, James Morris <jwm.art....@gmail.com> wrote: > I've ended up going back to Fons's pragmatism. If > non-blocking/lock-free programming is so impossibly difficult, > requiring intimate hardware knowledge of numerous different > architectures then there's only one solution available to people like > me, and that's to code for AMD64/Intel and use the existing ringbuffer > implementations.
Perhaps the pragmatic solution is to _lock_ the shared buffer? I'm not at all sound on this subject, but I wouldn't be surprised if Dan was right that memory ordering guarantees on the read/write index variables might still leave the data that is just "copied into the buffer" exposed to cache coherency problems. I know taking locks in a RT process is deeply frowned upon around here, but a critical section juts across the code used to update the buffer and read back from it -- with an accompanying guarantee of actually getting the right data out again -- might not be such a bad tradeoff these days as we'd be inclined to think? Chris _______________________________________________ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
