There are two files in the file section of this list. I scanned the
emails of this list quickly and I think they both ran fine for many
people and failed for some. You'll have to see for yourself. The
discussion thread starts here:

http://tech.groups.yahoo.com/group/liblf-dev/message/136

bjorn

On Oct 31, 2008, at 3:17 PM, oja_i_i wrote:

> --- In liblf-dev@yahoogroups.com, Bjorn Roche <bjorn@...> wrote:
> >
> >
> > On Oct 30, 2008, at 5:10 PM, James McCartney wrote:
> >
> > > On Wed, Oct 29, 2008 at 11:37 AM, Bjorn Roche <bjorn@...>
> > > wrote:
> > > > Plus, gcc, for example, tends to
> > > > insert memory barriers in places, like at function calls.
> > >
> > > I really don't think so. citation?
> > >
> >
> > I can't find a citation right now, so I could be wrong. If I am
> wrong,
> > sorry about that. It's obviously not behavior to count on anway,
> since
> > even if you know you are always working with gcc functions can be
> > inlined.
>
> I've read so many citations, and other theories about ring buffers and
> memory barriers. But to me they're useless until someone can write a
> piece of code that fails when barriers are absent and succeeds when
> they're in, and thus proves they are needed.
>
> Theories should help writing such a test case, but for now, I (and
> others on linux-audio-dev and jack-devel) couldn't figure that out. Or
> better said, we thought we did, but running it on the most vulnerable
> hardware we could think about (PPC SMP), we observed no failure.
>
> Any link, suggestion?
>
> --
> Olivier Guilyardi / Samalyse
>
>
>

-----------------------------
Bjorn Roche
XO Wave
Digital Audio Production and Post-Production Software
http://www.xowave.com
http://blog.bjornroche.com
http://myspace.com/xowave