Re: [Jack-Devel] Volatile vs memory fences

PrevNext  Index
DateSat, 05 Dec 2015 18:29:03 +0100
From Xavier Mendez <[hidden] at jmendeth dot com>
ToSean Bolton <[hidden] at smbolton dot com>, JACK <[hidden] at lists dot jackaudio dot org>
In-Reply-ToSean Bolton Re: [Jack-Devel] Volatile vs memory fences
Follow-UpSean Bolton Re: [Jack-Devel] Volatile vs memory fences
El 05/12/15 a les 18:04, Sean Bolton ha escrit:
> Hi Xavier,
>
> On Sat Dec  5 2015, Xavier Mendez wrote:
>> I was reviewing the code for `jack_ringbuffer` and I saw it uses
>> `volatile` for the pointers. This confused me, since my teachers have
>> long insisted that `volatile` isn't for use on multithreaded code.
>>
>> Take i.e. `jack_ringbuffer_write`: the hardware could reorder the
>> writes so that the pointer is updated before the buffer has been
>> written. Wouldn't a memory fence be required?
>
> You're quite right--memory barriers are required for safe operation of
> the ringbuffer on systems with weak memory ordering. IIRC, this is
> at least the third time this has come up on the list (see [1] for one
> previous discussion),
Oh, sorry for bringing the subject up again then. The search function of 
the archives doesn't seem to work...

> but it's never been fixed. The number of people
> running jack on affected hardware is very small, and it is difficult to
> convince people that the current code could fail on those systems. Take
> a look at the PortAudio ringbuffer if you'd like to see it done right.
Thanks, I'll take a look!

>
> -Sean
>
> [1] jack-devel mailing list, 22 Oct 2008, "Re: latest svn commit: 64/32
> support". http://comments.gmane.org/gmane.comp.audio.jackit/17887
>
PrevNext  Index

1449336552.12868_0.ltw:2, <56631EDF.4000707 at jmendeth dot com>