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

From: James Morris <james@email-addr-hidden-art.net>
Date: Tue Feb 28 2012 - 03:43:47 EET

On Mon, 27 Feb 2012 20:01:18 -0500
Paul Coccoli <pcoccoli@email-addr-hidden> wrote:

> On Mon, Feb 27, 2012 at 8:04 AM, Fons Adriaensen
> <fons@email-addr-hidden> wrote:
> > On Mon, Feb 27, 2012 at 09:59:19AM +0100, Nick Copeland wrote:
> >
> >> Both of these methods are affectively the same, what you are
> >> trying to do is provide a method that the low prio thread is
> >> responsible for both malloc and free.
> >
> > That's a nice method, it effectively uses the LFQ to 'send back' an
> > item after use by the recipient. It depends on the particular
> > implementation of the queue, you need one that allows to read one
> > (or more if necessary) items without moving the read pointer - that
> > should be done only after the data has been used since it signals
> > that the data can be freed.
> >
> > The alternative is to make this explicit, by having two pairs of
> > indices operate on the same buffer:
> [SNIP]
>
> Why not just use 2 ringbuffers: one to send pointers to the RT thread,
> and a second to send them back to the low prio thread (so it can free
> them). You probably need a semaphore for the return ringbuffer, but
> that should be RT-safe.

That's what I thought... would be better for someone who is new to real
time threads and memory allocation... and is what I decided on... minus
the semaphore.

So why is a semaphore needed? If the RT thread only sends an item back
when it absolutely no longer will use it?

James.

> _______________________________________________
> Linux-audio-dev mailing list
> Linux-audio-dev@email-addr-hidden
> http://lists.linuxaudio.org/listinfo/linux-audio-dev

-- 
http://jwm-art.net/
image/audio/text/code/
_______________________________________________
Linux-audio-dev mailing list
Linux-audio-dev@email-addr-hidden
http://lists.linuxaudio.org/listinfo/linux-audio-dev
Received on Tue Feb 28 04:15:02 2012

This archive was generated by hypermail 2.1.8 : Tue Feb 28 2012 - 04:15:02 EET