Hi Paul, On Jul 8, 2011, at 1:49 PM, Paul Davis wrote:
this is why we don't care about the types of stuff that Dan Muresan mentioned, except to the extent that it could actually lead to the computation of data/space available being wrong in a deeper way.
You're missing the point of what Dan was pointing out (and that I pointed out the last time we hashed through this.) It's not the space available computation that is at risk of failure--you're quite right about that. The potential for failure he's referring to is that on systems with weak memory ordering, a single-writer single-reader lock-free ring buffer without memory barriers (like JACK's) is at risk for the data read by the reader process becoming corrupted, when a data pointer update becomes visible to the reading processor before the data itself becomes visible. On Jul 8, 2011, at 6:21 AM, Paul Davis wrote:
...but as oliver mentioned, we've done some fairly exhaustive testing...
Really? I don't remember anyone reporting test results for an SMP Alpha, or a Sparc v9 running in RMO mode (i.e. under linux), or a multiprocessor (not just multicore) G5. Not to mention any of the newer processors released in the last 2.5 years. More to-the-point, exhaustive testing to prove the non-existence of a behavior that is expected to be fairly uncommon to begin with, on every processor where the code is ever likely to be run? That's a fool's errand. Better to just follow the recommendations of the respective ABIs, and put in the memory barriers for those platforms that need them, like PortAudio, the linux kernel, and most other implementations do. Hope that's useful, it would be nice to put this subject to bed. -Sean
_______________________________________________ Linux-audio-dev mailing list [email protected] http://lists.linuxaudio.org/listinfo/linux-audio-dev
