12 Jul
2011
12 Jul
'11
12:27 a.m.
[oops forgot to CC the list at first]
On 07/11/2011 11:15 PM, Tim E. Real wrote:
On July 11, 2011 04:50:06 pm Chris Cannam wrote:
The latter. The real-time thread would block until the other thread
(that currently holding the lock) releases the lock.
How long it takes until the other thread releases the lock is undefined
(context switches, process priority dependent, etc) and thus the concept
is not suitable for real-time.
I know taking locks in a RT process is deeply
frowned upon
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 same reason why other things like 'malloc'
or 'new' are not
recommended either?
Yes. malloc, printf, etc can not guarantee to return in time.
Allocation of new memory may involve various system-calls, flush
cache-lines, result in swapping, context-switches, etc... On most
systems the worst-case execution time it takes to allocate new memory
can not be guaranteed to be below a certain limit.
There are various attempts to provide constant time - O(1) - memory
allocation and de-allocation code for real-time systems. None of them
have reached widespread adoption. Often the drawbacks (e.g. decreased
available memory due to fragmentation) outweigh the benefits, and
pre-allocation on application level is easier to implement.
HTH,
robin
Thanks. Tim.
_______________________________________________
Linux-audio-dev mailing list
Linux-audio-dev(a)lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-dev