> 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
Attachment:
signature.asc
Description: OpenPGP digital signature
