[LAD] a *simple* ring buffer, comments pls?

Robin Gareus robin at gareus.org
Mon Jul 11 22:27:32 UTC 2011


[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 at lists.linuxaudio.org
> http://lists.linuxaudio.org/listinfo/linux-audio-dev



More information about the Linux-audio-dev mailing list