In your case - assuming you could already use DEADLINE for !root - do
you think you would need to use the same interface for the multiple
threads you are distributing work among? Or would you be fine with
assigning runtime/deadline for each one of those?

that's a tricky question and depends on the use-case: for me it's "good
enough" to use something like:

main audio thread:
while running:
  snd_pcm_read  // blocks until data is delivered from ALSA
  wake helper(s)
  do work()
  sync_with_helper(s)
  snd_pcm_write // blocks until data is delivered to ALSA

alsa is basically driven by the hardware, which delivers/requests data
every ~1.3ms.


distributing the work is a little tricky: to avoid excessive scheduling
overhead, the worker threads are typically woken up (after snd_pcm_read)
and the result is collected where sync_with_helper() typically boils
down to busy waiting. in this case, the workers as rate-monotonic in a
similar manner as the main audio thread.

one could also use lock-free queues with semaphores to wake only as many
threads as needed for the graph topology (which can depend on user
input). in this case SCHED_FIFO sounds more suitable.

--

from a practical point of view: i'm not targeting a safety critical
system. one advantage i'm seeing of DEADLINE over FIFO/RR is that it's
easier to prevent lockups (e.g. when a user overloads the system). in
the linux audio world this is typically done by a watchdog thread. the
other part of the unix world (mach) is using time-constraint threads by
default for audio use cases. so i'd assume that DEADLINE would free me
from the need to spawn the watchdog thread ...

cheers,
tim