Re: [linux-audio-dev] lock-free data structures

New Message Reply About this list Date view Thread view Subject view Author view Other groups

Subject: Re: [linux-audio-dev] lock-free data structures
From: Joshua Haberman (joshua_AT_reverberate.org)
Date: Fri Jun 18 2004 - 06:22:29 EEST


On Jun 17, 2004, at 10:50 AM, Benno Senoner wrote:
> Joshua:
> if you want an easy to use Lock-Free FIFO template in C++ look at
> RingBuffer.h in the LinuxSampler CVS
> We use this template heavily.

At the moment I am favoring an approach that uses multiple discrete
buffers and passing pointers to them, rather than pushing data on a
ring buffer. One major reason is that it allows you to send the data
to multiple places. Say you want to send a captured buffer to both the
disk thread (for recording) and the GUI thread (for displaying a VU
meter). With ring buffers you would have to copy this data to two
separate ring buffers, one for each thread that will read it. With
multiple buffers, you can just send the same pointer to both threads.

Also, I have a strategy in mind for gracefully degrading when the GUI
thread can't pull data from the FIFO fast enough (again, for VU meters
or some other kind of visualization). Instead of queuing up more and
more unconsumed buffers, I will give the FIFO an upper limit, a number
of buffers past which it will discard the oldest buffers. It's not
immediately clear to me how you could implement this same strategy with
a ring buffer.

Also, though I'm not sure yet if this matters for what I'm doing, your
ring buffer can only handle one reader and one writer. The algorithms
we are implementing can handle multiple readers and writers (though we
are writing single-reader/single-writer versions also, since they are
simpler and more efficient).

One final thing: I'm not sure if this is a problem in practice, but
most (if not all) processors do not guarantee that memory reads and
writes are performed in order, as observed by other processors and by
I/O devices. This could theoretically lead to a problem where the
stores that write data to the ring buffer are not performed until
*after* the store that updates your write pointer. Your reader thread
could get old data rather than the data your just wrote. To guarantee
that the loads and stores are observed in the required order, you have
to use memory barriers (again, in theory). See:

http://en.wikipedia.org/wiki/Memory_barrier

(Ross wrote that and we're both still learning about this stuff, so
don't take that article as the word of God).

Josh


New Message Reply About this list Date view Thread view Subject view Author view Other groups

This archive was generated by hypermail 2b28 : Fri Jun 18 2004 - 06:18:29 EEST