5 Dec
2015
5 Dec
'15
4:18 a.m.
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?
I appreciate your responses, I'm quite a noob when it comes to lock-free
programming...
Thank you,
Xavi
5 Dec
5 Dec
10 a.m.
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), 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.
-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
10:29 a.m.
El 05/12/15 a les 18:04, Sean Bolton ha escrit:
Hi Xavier,
On Sat Dec 5 2015, Xavier Mendez wrote:
Oh, sorry for bringing the subject up again then. The search
function of
the archives doesn't seem to work...
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), 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
11 a.m.
El 05/12/15 a les 18:41, Sean Bolton ha escrit:
On Sat Dec 5 2015, Xavier Mendez wrote:
If it helps, I intend to run JACK on Android; the Android audio team
explicitely said ringbuffers without memory barriers won't work.
Oh, sorry for bringing the subject up again then.
The search function
of the archives doesn't seem to work...
Don't say sorry--maybe as a result of you bringing it up this time, it
will finally get fixed!
-Sean
8 Dec
8 Dec
7 a.m.
New subject: [Jack-Devel] (OT) How do so many of you not publish SPF records?
The recent thread on memory fences went almost entirely into my spam
folder, because SPF records for mail servers used by people on this list
are missing or wrong. It's almost 2016; SPF really isn't optional
anymore. Please contact your system administrators and fix your DNS.
# dig +short TXT linuxaudiosystems.com
# dig +short TXT spectralbird.de
# dig +short TXT drcomp.erfurt.thur.de
#
David Nielson
On 12/06/2015 05:55 PM, Paul Davis wrote:
On Sat, Dec 5, 2015 at 12:04 PM, Sean Bolton <sean(a)smbolton.com
<mailto:sean@smbolton.com>> wrote:
it is difficult to
convince people that the current code could fail on those systems
not difficult to convince me. I'd just like to see a working patch
which I will happily apply.
_______________________________________________
Jack-Devel mailing list
Jack-Devel(a)lists.jackaudio.org
http://lists.jackaudio.org/listinfo.cgi/jack-devel-jackaudio.org
9:19 a.m.
New subject: [Jack-Devel] (OT) How do so many of you not publish SPF records?
On Tue, Dec 8, 2015 at 9:00 AM, David Nielson <david(a)naptastic.com> wrote:
The recent thread on memory fences went almost
entirely into my spam
folder, because SPF records for mail servers used by people on this list
are missing or wrong. It's almost 2016; SPF really isn't optional anymore.
Please contact your system administrators and fix your DNS.
# dig +short TXT linuxaudiosystems.com
duly added. more subtle than you might think, because linuxaudiosystems.com
is both an actual host and also for MX purposes handled by google.
3292
days inactive
3295
days old
jackaudio@lists.linuxaudio.org
7 comments
4 participants
participants (4)
-
David Nielson -
Paul Davis -
Sean Bolton -
Xavier Mendez