Subject: Re: [linux-audio-dev] lock-free ring buffer code
From: torbenh_AT_gmx.de
Date: Fri Apr 04 2003 - 18:03:54 EEST
On Thu, Apr 03, 2003 at 03:14:53PM -0500, rm wrote:
> On Thu, Apr 03, 2003 at 11:31:29AM -0800, Tim Hockin wrote:
> > > courtesy of paul davis:
> > >
> > > you should use a lock free ringbuffer. we will be adding example code
> > > to the example-clients directory soon. existing code is in ardour's
> > > source base (for C++). the example code will be in
> > > example-clients/capture_client.c.
> > >
> > > where ardour is ardour.sf.net. (i doubt there is anything hugely non-C in
> > > the ringbuffer code proper).
> >
> > maybe it's just me, but I can't find said file...?
>
> hmmm i noticed after i posted that it said, "we will be adding". so
> it's not there yet, but it will be eventually. there are examples of
no it is not there.
the current code uses mutex_lock and and a condition.
> it in the ardour code though.
>
> try looking at
>
> http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/ardour/ardour/libs/pbd/ringbuffer.cc
>
> ie ( ardour/libs/pbd/ringbuffer.cc ) in the source distribution.
>
> click on the rev 1.2 (view) link.
The problem i have with the current ringbuffer, is that it does not
solve the synchronization of the non realtime thread to the realtime
thread. what should be done when you cant write to the buffer ?
usleep( a_sensible_value ); ?
wouldnt it be nicer to wakeup the non realtime thread with a condition ?
the galan ogg-reader starts a reader thread and two gasync queues...
then i have 2
struct buffer { SAMPLETIME timestamp; SAMPLE buffer[SIZE]; } *
which are passed between the reader and the realtime thread;
reader fills in buffer and realtime fills in the timestamp, so the
reader thread knows where it should read next.
this implementation is just the same as the current capture_client in
jack.
>
> (note that the mlock/unlock stuff is for locking the buffer region
> into memory).
>
> below is what i use (i think it works). the primary thing to notice
> is that readers and writers are kept in line by the atomicity of
> integer assignment (though in general, we should probably declare them
> atomic_t or something).
yeah... that is the principle of the lock free ringbuffer.
>
> another thing to note is that this allows one writer and one reader to
> communicate asynchronously in one direction (where one writer and one
> reader may be a group of writers and readers who are synchronous with
> respect to their group members). the important thing is that one group
> must always be the writers and one group must always be the readers
> and they may not switch at any time.
but how is synchronisation done ?
this is my main problem with it.
the problem with gasync queue is that a queue is not a threadsafe
data structure. so it should be possible to modify the gasync queue to
have a ringbuffer instead of a queue and then only use a mutex for the
condition signaling. g_cond_signal can be called without holding the
mutex so that should be ok for this case.
-- torben Hohn http://galan.sourceforge.net -- The graphical Audio language
This archive was generated by hypermail 2b28 : Fri Apr 04 2003 - 14:34:33 EEST