Re: [LAD] a *simple* ring buffer, comments pls?

>> 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.
using preempt_rt, the scheduling latency can be very low (like 10 microseconds),
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).

however one can avoid the scheduling latency by using spinlocks if one can
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.

tim

_______________________________________________
Linux-audio-dev mailing list
Linux-audio-dev@email-addr-hidden
http://lists.linuxaudio.org/listinfo/linux-audio-dev
Received on Tue Jul 12 12:15:02 2011