[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: >> 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 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. > 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@lists.linuxaudio.org > http://lists.linuxaudio.org/listinfo/linux-audio-dev _______________________________________________ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev