Re: [LAD] jack ringbuffer question

On Dec 2, 2009, at 7:33 AM, lieven moors wrote:
> Paul Davis wrote:
>> On Tue, Dec 1, 2009 at 9:51 PM, lieven moors
>> <lievenmoors@email-addr-hidden> wrote:
>>
>>> I want to repeat the same Arp, until there is an update to the
>>> text file.
>>> One arp is allready
>>> loaded in each ringbuffer in main(). When the file is modified, a
>>> second one
>>> is added, and
>>> process skips to the second one. Since I have only space for two
>>> arps in the
>>> buffer, there
>>> should always be exactly one which is readable. I know it is a
>>> bit weird,
>>> but it seems to
>>> work, apart from the problem I described.
>>>
>>
>> sounds as if you might want to look into atomic pointer and/or
>> integer
>> exchange instead, to get lock-free double buffering.
>>
>> ringbuffers are generally for passing streaming data/events.
>>
> Could you give me a hint on how to use atomic pointers?
> Should I use __sync_val_compare_and_swap from GCC?
> I've been looking around for other libraries, but I'm not sure
> where to
> start.
> Also, what did you mean with 'integer exchange'?
> Is it yet another way of using CAS?

All of that stuff is great to learn about, but on the other
hand, you've already got the hang of the ringbuffer API -- why
not just use that? The way I usually deal with this sort of
thing is to have two ringbuffers, one from the worker thread to
the process thread, and one from the process thread back to the
worker thread. Worker (inotify) thread creates a new Arp, and
passes a pointer to it through the ring buffer to the process
thread. Process thread then reads the new Arp pointer from the
first ringbuffer, begins to use it, and passes a pointer to the
old Arp back through the second ringbuffer to the worker thread.
Worker thread then reads the old Arp pointer from the second
ringbuffer, and frees or reuses it.

Disadvantage to this is it's not quite as efficient as an atomic
pointer exchange, but the advantage is you've already got everything
you need right there in jack, no need for an extra library.

HTH,

-Sean

_______________________________________________
Linux-audio-dev mailing list
Linux-audio-dev@email-addr-hidden
http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev
Received on Thu Dec 3 08:15:02 2009