Re: RT patch acceptance

[Lee Revell <rlrevell@joe-job.com>]

On Fri, 2005-05-27 at 09:18 +0200, Ingo Molnar wrote:
> but it's not like hard-RT tasks live in a vacuum: they already have to 
> be aware of the latencies caused by themselves, and they have to be 
> consciously aware of what kernel facilities they use. If you do hard-RT
> you have to be very aware of every line of code your task may execute.
> 
> > So in that sense, if you do hard RT in the Linux kernel, it surely is 
> > always going to be some subset of operations, dependant on exact 
> > locking implementation, other tasks running and resource usage, right?
> 
> yes. The goal is that latencies will fundamentally depend on what 
> facilities (and sharing) the RT task makes use of - instead of depending 
> on what _other_ tasks do in the system.

Real world example: JACK clients form an ordered graph and each must
finish processing a chunk of audio before signaling the next client to
start.  The audio lives in shared memory and FIFOs are used for the IPC
between RT threads; when each client finishes it writes a single byte to
a fifo which wakes the next client, etc.

(we have to use FIFOs because signals are too slow and futexes are not
available on 2.4)

Of course write() will not normally be RT safe, as it can call down into
the journaling code or whatever, but on a tmpfs/shmfs writing a byte to
a FIFO takes constant time, so as long as the user makes sure the FIFOs
are set up correctly it's all 100% RT safe.

Lee