Re: [LAD] memory allocation for the real time thread, opinions wanted

Previous message: [thread] [date] [author]
Next message: [thread] [date] [author]
To: Adrian Knoth <adi@...>
Cc: <linux-audio-dev@...>
Date: Monday, February 27, 2012 - 8:39 am

[Adrian Knoth]

>Iain Duncan wrote:

This, I'm afraid, is an idea with a fair share of issues. It does not
seem a trivial problem to estimate the total memory needs of a
reasonably complex application. And even if you can solve this, you
will find that common malloc implementations (such as the one in
glibc) protect the heap with mutexes. Regardless of memory
availability, your real-time thread can always stall in malloc() or
free() when a heap mutex is found locked by another thread.

As for the original question, I'd suggest handling the maintenance and
memory management of large lists of events in low-priority,
low-frequency threads. These threads periodically feed the realtime
thread bursts of a small number of events, ahead of time and using
preallocated FIFO queues which can be of reasonably modest size. (In
fact, I seem to remember that this approach has been discussed on this
list recently, if perhaps briefly.)

Cheers, Tim
Linux-audio-dev mailing list

Previous message: [thread] [date] [author]
Next message: [thread] [date] [author]

Messages in current thread:
Re: [LAD] memory allocation for the real time thread, opinio..., Tim Goetze, (Mon Feb 27, 8:39 am)