[LAD] Writing to an eventfd from a realtime thread

[William Light]

On Wed, 24 Sep 2014, at 14:12, Clemens Ladisch wrote:
> 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.

That's encouraging, okay.

> (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