24 Sep
2014
24 Sep
'14
1:21 p.m.
Hey everybody,
I've got this audio app I'm writing which uses message passing to
communicate between threads (similar to the actor model). A message
channel consists of a ring-buffer for the actual message storage, and
then an eventfd so that a thread can block on its channel (or,
importantly, several).
At the moment, when the audio thread (the JACK callback) needs to send a
message over a channel to another thread, it follows the common codepath
of appending the message to the channel's ring-buffer and then
write()ing to the eventfd. I suspect this is not real-time safe, but is
it something I should lose sleep over?
-w
24 Sep
24 Sep
2:12 p.m.
William Light wrote:
At the moment, when the audio thread (the JACK
callback) needs to send a
message over a channel to another thread, it follows the common codepath
of appending the message to the channel's ring-buffer and then
write()ing to the eventfd. I suspect this is not real-time safe, but is
it something I should lose sleep over?
Well, you should know how your ring buffer behaves (i.e., if it drops
the message or blocks when it overflows).
As for the eventfd, it could block only if the counter value
exceeded 0xfffffffffffffffe. I'd guess your ring buffer cannot get
that big.
(With the ring buffer and the eventfd, you are implementing what looks
like a pipe. If you need to copy the data to the ring buffer anyway,
and if your messages and the entire buffer fit into the pipe limits
(4 KB and 1 MB), you could simply use a pipe to begin with; see
<http://man7.org/linux/man-pages/man7/pipe.7.html>.)
Regards,
Clemens
2:28 p.m.
On Wed, 24 Sep 2014, at 14:12, Clemens Ladisch wrote:
William Light wrote:
That's encouraging, okay.
At the moment, when the audio thread (the JACK
callback) needs to send a
message over a channel to another thread, it follows the common codepath
of appending the message to the channel's ring-buffer and then
write()ing to the eventfd. I suspect this is not real-time safe, but is
it something I should lose sleep over?
Well, you should know how your ring buffer behaves (i.e., if it drops
the message or blocks when it overflows).
As for the eventfd, it could block only if the counter value
exceeded 0xfffffffffffffffe. I'd guess your ring buffer cannot get
that big. (With the ring buffer and the eventfd, you are
implementing what looks
like a pipe. If you need to copy the data to the ring buffer anyway,
and if your messages and the entire buffer fit into the pipe limits
(4 KB and 1 MB), you could simply use a pipe to begin with; see
<http://man7.org/linux/man-pages/man7/pipe.7.html>.)
Yes, that's roughly what I've got, I'm implementing something similar to
Go's channels (actor message queues, basically). I shied away from pipes
initially because I figured that staying in user-space would let me keep
tighter control on how quickly things execute. I've been following the
JACK recommendation of avoiding "all I/O functions (disk, TTY, network)"
as strictly as possible, which is why I'm curious about whether
write()ing to an eventfd will imperil me. If I could safely use a pipe
instead of an all-memory ringbuffer and signaling mechanism, I may just
do that.
I'm avoiding blocking, of course, but I'm also worried about the
potential scheduling implications of jumping into kernel-mode and back,
and also the potential non-determinism of system call execution time.
Are these things I should actually worry about?
-w
2:39 p.m.
[William Light]
I'm avoiding blocking, of course, but I'm also
worried about the
potential scheduling implications of jumping into kernel-mode and back,
and also the potential non-determinism of system call execution time.
Are these things I should actually worry about?
I've been using pipes for message-passing the way Clemens mentioned in
realtime MIDI and audio threads for years without ever experiencing any
scheduling or blocking problems.
Cheers, Tim
3:28 p.m.
William Light wrote:
I shied away from pipes initially because I figured
that staying in
user-space would let me keep tighter control on how quickly things
execute.
User-space code can be swapped out (unless you have mlocked it). So
_replacing_ user-space code with some kernel code that already does the
same thing cannot make things worse.
I've been following the JACK recommendation of
avoiding "all I/O
functions (disk, TTY, network)" as strictly as possible
That kind of I/O goes to real devices, which might have all sorts of
unpredictable delays.
In the case of an eventfd (or a pipe that is not connected to another
program), your program controls all aspects of the object, so you know
when it could block. Furthermore, operations will not block if you have
enabled non-blocking mode.
I'm avoiding blocking, of course, but I'm also
worried about the
potential scheduling implications of jumping into kernel-mode and back
System calls executed from your process get accounted to your process,
just like user-space code. Interrupts can interrupt both kernel- and
user-space code.
Scheduling happens only when your time slice runs out (which can happen
in both user space and kernel space), or when you make a system call
that actually blocks.
Regards,
Clemens
4:03 p.m.
On Wed, Sep 24, 2014 at 7:21 AM, William Light <wrl(a)illest.net> wrote:
Hey everybody,
I've got this audio app I'm writing which uses message passing to
communicate between threads (similar to the actor model). A message
channel consists of a ring-buffer for the actual message storage, and
then an eventfd so that a thread can block on its channel (or,
importantly, several).
At the moment, when the audio thread (the JACK callback) needs to send a
message over a channel to another thread, it follows the common codepath
of appending the message to the channel's ring-buffer and then
write()ing to the eventfd. I suspect this is not real-time safe, but is
it something I should lose sleep over?
we're still missing measurements on the performance of semaphores, fifo's
and eventfd's when used for this purpose on modern linux. JACK itself uses
FIFOs (pipes) on Linux because 10+ years ago they were the fastest and most
reliable. nobody knows for sure right whether that is still true.
4:34 p.m.
On Wed, 24 Sep 2014, at 16:03, Paul Davis wrote:
On Wed, Sep 24, 2014 at 7:21 AM, William Light
<wrl(a)illest.net> wrote:
I'm particularly interested in primitives that I can poll() on, which
(on Linux, at least) narrows me down to things that I can get a file
descriptor for (at least, as far as I understand).
However, a while back I was curious about the same thing, so I hacked
this thing together. Not sure if this is the best testing methodology
(in fact, looking back at the code, I'm not sure what my concept was),
but at least it could be a starting point.
https://github.com/wrl/thread-sync-latency-tests
-w
Hey everybody,
I've got this audio app I'm writing which uses message passing to
communicate between threads (similar to the actor model). A message
channel consists of a ring-buffer for the actual message storage, and
then an eventfd so that a thread can block on its channel (or,
importantly, several).
At the moment, when the audio thread (the JACK callback) needs to send a
message over a channel to another thread, it follows the common codepath
of appending the message to the channel's ring-buffer and then
write()ing to the eventfd. I suspect this is not real-time safe, but is
it something I should lose sleep over?
we're still missing measurements on the performance of semaphores, fifo's
and eventfd's when used for this purpose on modern linux. JACK itself
uses
FIFOs (pipes) on Linux because 10+ years ago they were the fastest and
most
reliable. nobody knows for sure right whether that is still true. 
25 Sep
25 Sep
12:15 a.m.
You could also use a jack_rigbuffer_t, its lock free and hence should be RT
thread safe.
You could write a known msg into the ring buffer from the RT thread,
receive the msg from non real-time thread and do event passing from there.
--
Regards,
Karthik Poduval
On Wed, Sep 24, 2014 at 5:39 AM, Tim Goetze <tim(a)quitte.de> wrote:
[William Light]
I'm avoiding blocking, of course, but I'm
also worried about the
potential scheduling implications of jumping into kernel-mode and back,
and also the potential non-determinism of system call execution time.
Are these things I should actually worry about?
I've been using pipes for message-passing the way Clemens mentioned in
realtime MIDI and audio threads for years without ever experiencing any
scheduling or blocking problems.
Cheers, Tim
_______________________________________________
Linux-audio-dev mailing list
Linux-audio-dev(a)lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-dev
12:46 a.m.
On Wed, Sep 24, 2014 at 6:15 PM, karthik poduval <karthik.poduval(a)gmail.com>
wrote:
You could also use a jack_rigbuffer_t, its lock free
and hence should be
RT thread safe.
You could write a known msg into the ring buffer from the RT thread,
receive the msg from non real-time thread and do event passing from there.
Nope. the poster is looking for a way to notify a different thread that it
would be worth checking out the contents of a ringbuffer.
There are only two ways to do this: either wake the other thread regularly
based on a timer, and hope that the chosen interval and accuracy are enough
to keep the buffer (empty|full) OR wake the other thread as needed. this
second option requires some sort of communication channel to the thread to
wake it, which could be (on linux) any of a pthread_condvar, a semaphore, a
FIFO/pipe, and eventfd, etc. etc.
3510
days inactive
3510
days old
linux-audio-dev@lists.linuxaudio.org
8 comments
5 participants
participants (5)
-
Clemens Ladisch -
karthik poduval -
Paul Davis -
Tim Goetze -
William Light