0

In audio threads, I've been told it's good style to not use syscalls like e.g. printf() because they give control back to the kernel, which can then decide to continue with another thread, which means your audio thread can lose a lot of time. I found the idiom strange because modern Linux kernels could still interrupt the audio thread (preemption). Maybe, however, there's no (or very limited) preemption if the audio thread has RT prio...

Does Linux prempt a thread if all other running threads have lower priority?

Is the behaviour different between realtime and non-realtime kernels?

4
  • If the printf call leads to a synchronous write and the thread blocks because the CPU has to wait for I/O, then the thread is preempted and some other thread is run (if available). The OS will not let the CPU sit on its hands when there is work to be done. – Johan Myréen Jun 28 '19 at 8:43
  • As soon as the I/O is finished, will the realtime job get its control back by the kernel preempting other jobs? – Johannes Jun 28 '19 at 12:55
  • Yes, if the real-time thread wakes up (changes state to runnable) and a lower-priority thread is running on a CPU (or a CPU is idle), then the real-time thread gets the CPU and starts running again. So the thread is only blocked as long as the write takes to return, unless there is some other real-time thread with equal priority, which is scheduled instead. The Linux kernel does not preempt a running thread if all other threads have lower priority. – Johan Myréen Jun 28 '19 at 13:57
  • But then, why should one avoid syscalls in general? From what you say, only the waiting time matters, because the rt thread will get back control immediatelly. It's clear that printf will take some time for IO. But what about e.g. mutex locking? That should not cause IO wait time... – Johannes Jun 28 '19 at 19:21

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Browse other questions tagged or ask your own question.