linuxaudio.org

On 07/12/2011 10:27 AM, Tim Blechmann wrote:

quoted text
>>> OTOH, if you have a number of threads at the same priority

>>> as Jack's and doing audio work (e.g. to use all the CPUs of

>>> an SMP machine) then using locks between them (but no other

>>> threads) should be OK - depending a bit on how they are used.

>> So, you can use locks as long as that's only meant to synchronize realtime

>> threads with each other? Should some master thread (could be the JACK process

>> thread) have a realtime priority slightly higher than the other (worker)

>> realtime threads? What are the caveats in general?

>

> yes and no: it is perfectly fine to use locks to use multiple real-time threads,

> but the thread A fails to acquire a lock, it will be suspended and woken up once

> thread B releases the lock. the time between `B releases the lock' and `A

> resumes its execution' is the scheduling latency, which is both os and hardware

> related.

I understand.
> using preempt_rt, the scheduling latency can be very low (like 10 microseconds),

quoted text
> if cpu frequency scaling is applied or smt/hyperthreading is enabled it can be

> as high as 250 microseconds (which is already quite significant, if one is using

> small signal vector sizes).

That's interesting. We're actually benchmarking scheduling latency at the moment.
> however one can avoid the scheduling latency by using spinlocks if one can

quoted text
> ensure that none of the synchronized threads can be preempted. personally i

> achieve this by (a) using real-time scheduling, (b) using not more real-time

> threads than physical cores and (c) pinning the rt threads to separate cores.

Ah yes, you ensure that threads run on separate cores. That really makes sense.

Thanks for the tip.
--

  Olivier

_______________________________________________

Linux-audio-dev mailing list

Linux-audio-dev@lists.linuxaudio.org

http://lists.linuxaudio.org/listinfo/linux-audio-dev