12 Jul
2011
12 Jul
'11
11:01 a.m.
On 07/12/2011 10:27 AM, Tim Blechmann wrote:
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.
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? 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).
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
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