On 3/1/2016 11:40 AM, Paul Davis wrote:
the JACK implementation relies on two things to work:
* pointer and integer operations are (weakly) atomic on all
platforms that JACK runs on
* code reordering will either not happen or will be prevented by
the compiler
Does #2 mean that -O3 shoul
On Wed, Mar 2, 2016 at 11:55 AM, Jonathan Brickman
wrote:
> On 3/1/2016 11:40 AM, Paul Davis wrote:
>
> the JACK implementation relies on two things to work:
>
>* pointer and integer operations are (weakly) atomic on all platforms
> that JACK runs on
>* code reordering will either not hap
On Wed, Mar 2, 2016 at 5:55 PM, Jonathan Brickman wrote:
> On 3/1/2016 11:40 AM, Paul Davis wrote:
>
> > the JACK implementation relies on two things to work:
> >
> >* pointer and integer operations are (weakly) atomic on all platforms
> > that JACK runs on
> >* code reordering will either
On Fri, Mar 4, 2016 at 1:22 PM, Kjetil Matheussen
wrote:
> You are right. There was even a discussion about how broken it was
> in 2008, and it was fixed, at least in practice.
>
> http://lists.linuxaudio.org/pipermail/linux-audio-user/2008-October/056000.html
>
> Theoretically (and not unlikely
kjetil, thanks for the patch.
however, the problem with fixing this problem has never been identifying
where to put the barriers, it has been adding them in a portable way.
__atomic_* are, as far as i can tell, gcc-specific. am i wrong about that?
On Fri, Mar 4, 2016 at 7:42 AM, Kjetil Matheussen
On Fri, Mar 4, 2016 at 2:12 PM, Paul Davis
wrote:
> kjetil, thanks for the patch.
>
> however, the problem with fixing this problem has never been identifying
> where to put the barriers, it has been adding them in a portable way.
> __atomic_* are, as far as i can tell, gcc-specific. am i wrong a
On Fri, Mar 4, 2016 at 2:21 PM, Kjetil Matheussen
wrote:
>
>
> On Fri, Mar 4, 2016 at 2:12 PM, Paul Davis
> wrote:
>
>> kjetil, thanks for the patch.
>>
>> however, the problem with fixing this problem has never been identifying
>> where to put the barriers, it has been adding them in a portable
On Fri, Mar 04, 2016 at 10:16:02AM +0100, Sebastian Gesemann wrote:
> As I said, I consider JACK's ringbuffer implementation to be broken.
> According to the C11/C++11 memory model there is nothing in the code
> that prevents reordering the update to write_ptr and the update to
> *buf in jack_ring
On Fri, Mar 4, 2016 at 11:21 PM, Fons Adriaensen wrote:
> On Fri, Mar 04, 2016 at 10:16:02AM +0100, Sebastian Gesemann wrote:
>
>> As I said, I consider JACK's ringbuffer implementation to be broken.
>> According to the C11/C++11 memory model there is nothing in the code
>> that prevents reorderin
>
> Control of memory ordering and atomics are officially part of the C
>
and C++ languages since 2011. GCC already supported this when the ISO
> standards was finalized. Microsoft and Clang started supporting it in
> 2012. So, it's been pretty much portable since 2012. This is 2016.
> IMHO, it's t
On Sat, Mar 5, 2016 at 1:12 PM, Kjetil Matheussen
wrote:
> Control of memory ordering and atomics are officially part of the C
>>
> and C++ languages since 2011. GCC already supported this when the ISO
>> standards was finalized. Microsoft and Clang started supporting it in
>> 2012. So, it's been
On Sat, Mar 5, 2016 at 1:28 PM, Kjetil Matheussen
wrote:
> On Sat, Mar 5, 2016 at 1:12 PM, Kjetil Matheussen
> wrote:
>>
>> Well, atomics are not an official part of the C standard, only the C++
>> standard.
>
> Ouch. Sorry. Wrong. C11 has stdatomic.h, but it's not included
> in gcc 4.x, which is
12 matches
Mail list logo
