[gst-devel] Real Time Workers (SCHED_FIFO)

[David Schleef]

On Tue, Jul 31, 2007 at 11:01:54AM +0300, Stefan Kost wrote:
> Hi,
> 
> Esben Stien wrote:
> > Stefan Kost <ensonic at hora-obscura.de> writes:
> > 
> >> imho SCHED_FIFO is a process wide seting. Thus if you call
> >> sched_setscheduler(9 for your process this also affects all
> >> gstreamer threads.
> > 
> > No, it doesn't. 
> > 
> > 20070222UTC150506 <wingo> b0ef: it wouldn't matter, the real work is
> > done in another thread
> > 20070222UTC150537 <b0ef> wingo: how about setting that worker thread
> > SCHED_FIFO?
> > 20070222UTC150610 <wingo> b0ef: unfortunately the answer is still no
> > -- realtime + gstreamer still needs design work.
> > 
> 
> I don't thinks that is right. Have you read the man page for sched_setscheduler?
> "Child processes inherit the scheduling algorithm and parameters across a fork()."
> 
> If it is even keep for a fork(), threads for sure inherit the setting too. Linux
> implements threads as lightweight processes.

You're looking for pthread_attr_setschedpolicy() and friends.

There are two main problems with running threads with SCHED_FIFO or
SCHED_RR.  One is that all the threading calls are wrapped by the
gthread code, so direct access to the pthreads interface for threads
is not really allowed.

Second, is that the gstreamer code isn't priority-inversion clean.
A real-time (ahem, *bounded-latency*) thread may need to grab a lock
held by a non-real-time thread, and that non-real-time thread could
be waiting for any number of unbounded events.  This can be solved
with a lot of thought, effort, and testing, mainly by using priority
inheriting mutexes, but glib doesn't have those.  Which brings me to
the third and fourth problems -- glib and glibc are not priority-
inversion clean, so resources shared between real-time and non-real-time
threads can cause problems.  Think g_slice_*() or malloc().

Thirdly, many elements have potentially unbounded delays.  This of
course isn't a problem if you choose your elements carefully, but
there's no information about which elements are safe, and we don't
currently have a policy or a how-to covering how to write such elements.

Of course, an application developer may not want/need bounded-latency
design guarantees, but just want it to work in practice.  In this case,
it would be a bajillion times easier to write the application using a
client/server model, with the gstreamer-based server running with a
real-time priority for the entire process.  That way, there are few
(if any) resource conflicts that can cause priority inversion.



dave...