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

Tim Blechmann tim at klingt.org
Tue Jul 12 08:27:30 UTC 2011


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





More information about the Linux-audio-dev mailing list