8 Jul
2011
8 Jul
'11
11:57 p.m.
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