On Mon, Jul 11, 2011 at 05:15:26PM -0400, Tim E. Real wrote:
> Likely been answered before, but good time for me to ask:
> What is the reason it is not recommended?
> Is it simply because of a long time involved in acquiring the lock, or is it
> because the lock might block some other Jack thread from running?
The time required to take a lock if it is free is probably
not significant in most cases (this should not involve a
system call).
The problem with e.g. a Jack callback trying to take a lock
is that the lock could be held by a non-RT thread, and you
have no idea how long it could take before that thread
releases it. Even if the Jack thread blocks waiting for
the lock, that doesn't mean the one holding the lock will
continue, and even if it does that provides no guarantee.
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.
> The same reason why other things like 'malloc' or 'new' are not
> recommended either?
These could take a long time in some cases (if your process
needs more memory from the system for example), so they can't
be used safely.
-- FA _______________________________________________ Linux-audio-dev mailing list Linux-audio-dev@email-addr-hidden http://lists.linuxaudio.org/listinfo/linux-audio-devReceived on Tue Jul 12 04:15:02 2011
This archive was generated by hypermail 2.1.8 : Tue Jul 12 2011 - 04:15:02 EEST