On 08/20/2018 01:54 PM, Tim Blechmann wrote:

quoted

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.

Hi Tim!

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.

When you say "rate-monitonic", do you mean that the worker threads with
smaller period (high rate, so) have a higher fixed-priority? If so, what
are the other periods?

as sync_with_helper() does a busy-wait, the "main audio thread" has a
relative lower priority than the worker threads, right?

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

So, your main wish here is to avoid having a watchdog thread to
"throttle" misbehaving workload/setup?

For curiosity, what are the "time-constraints" setup used on mach?

-- Daniel