Re: [LAD] a *simple* ring buffer, comments pls?

> >> > the main problem is the lack of a memory model for multi-threaded
> >> > applications at the level of the language (c or c++). fortunately this
> >> > is about to change with c++0x and probably c1x.
> >>
> >> So in 10 years we will be able to rely on a conformant compiler being
> >> available on all relevant platforms :)
> >
> > http://www.chaoticmind.net/~hcb/projects/boost.atomic/
>
> if it all works ... very nice.
>
> but note that its only been tested on a couple of versions of gcc on a
> couple of *nix-ish platforms.

the number of supported compilers in the documentation is outdated. it supports
the most commonly used compilers and multiple architectures.
if a compiler is not supported natively, it uses a fallback implementation based
on a pool of spinlocks, which of course is not lock-free, but c++0x doesn't
guarantee lock-freedom either ...

i've been using it for quite some time in boost.lockfree (in a slightly modified
version).

tim

_______________________________________________
Linux-audio-dev mailing list
Linux-audio-dev@email-addr-hidden
http://lists.linuxaudio.org/listinfo/linux-audio-dev