Re: [linux-audio-dev] realtimeness: pthread_cond_signal vs. pipe write

On Mon, 2006-06-05 at 01:21 +0200, Stefan Westerfeld wrote:
> Hi!
>
> I am trying to notify a high priority (nice -20 or nice -19) thread from
> a realtime thread (from a jack callback to be precise). Of course I want
> the realtime thread to not block, but I want the high priority thread to
> react as soon as possible. For the first implementation, I used a
> condition, and pthread_cond_signal. But as I can't aquire a mutex within
> the realtime thread, at least not always (at most with trylock()), this
> results in racy code.

int pipes[2];

RT-thread: char c;
           write (pipes[0], &c, 1);

other-thread: poll (.... on pipes[1] ... and others)

writing to a pipe is not 100% RT safe, but if the pipe is created in a
shm filesystem, its as close to it as you will get without ...

futexes, which are used by current NPTL code for pthread signalling.
they can still block, but they have the benefit that you do not need new
code to use them - just use pthreads calls.

this is why JACK (which uses the pipe model) puts its pipes into a shm
filesystem by the way - not doing so leads to horrible xruns on most
systems because locking the pipe involves interactions with a real
filesystem on disk.

> Now the question is: am I producing priority inversion, then? I've seen
> that the kernel code of pipe write has code like
>
> mutex_lock(PIPE_MUTEX(*inode));
>
> (in fs/pipe.c, linux-2.6.16.16), so can this mutex cause priority
> inversion?

no, because the high priority thread cannot wake up take the lock - the
RT thread is already holding it.

priority inversion happens when an higher thread attempts to acquire a
lock currently held by a lower priority thread. in the design of a
system based around relatively long time intervals between lock
acquisition (10ths of msecs to many msecs), the high priority thread
will always be acquiring the lock again long after the lower priority
thread has finished with it.

if you want to get all theoretical, then yes, any scheme that involves
interactions between higher and lower priority thread can lead to
priority inversion if there is no system-level help to prevent it. but
in systems built around the data flow inherent in all current audio and
video interfaces, it does not need to be an issue.

if you cannot ensure that the low priority thread will release the lock
long before the high priority needs it again, i'd suggest a redesign of
your code. it will happen more quickly than the kernel acquiring
priority inversion support.

--p
Received on Mon Jun 5 16:15:01 2006