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