[LAD] a *simple* ring buffer, comments pls?

Fons Adriaensen fons at linuxaudio.org
Mon Jul 11 20:44:26 UTC 2011


On Mon, Jul 11, 2011 at 03:02:57PM +0300, Dan Muresan wrote:

> Well, if you are content with any old possible value of xval (i.e. you
> have no synchronization on it anywhere), you are right; but then you
> might as well make xval a constant -- just use the first value it ever
> had. You have no guarantees that the thread calling f() will EVER have
> its hardware cache synchronized to whoever is producing xval. Cache
> coherency again...

The typical use case would be xval being some parameter used
by e.g. a Jack callback and updated by e.g. MIDI events, or 
a measurement; and f() being the code that runs periodically
to update the GUI element for that parameter or measurement.
There is no synchronisation and occasionally using an out-
dated value has no fatal consequences - it will very probably
be put right on the next update which is 1/10 second or so
in the future. The display is informative only, correct audio
processing does in no way depend on it being up to date.

> Otherwise, I bet you *do* have some synchronization, somewhere, for
> xval in the thread that calls f. Wherever that place is, save the
> cached value, i.e.
> 
> mutex_lock()
> x = xval
> mutex_unlock()
> f (x)

That would mean the other side has to use the mutex as well
when updating xval, and in a Jack callback that is 'not done',
at least not if the mutex could be held by a non-realtime
thread such as one updating the GUI.

> In the signal case, you should of course make sure the signal is
> caught by the thread who reads x, by using pthread_sigmask()
> appropriately. Or make the program non-threaded. Otherwise, you now
> have two problems...

Not if there is no synchronisation involved as in the example
above. If all the signal handler has to do is update xval, it
doesn't matter in which thread it runs.

> Also, strictly speaking if you're using a sighandler plus volatile,
> you should also declare xval as sig_atomic_t.

Strictly true, but R/W of ints is atomic on the platforms that 
matter to me.

Ciao,

-- 
FA




More information about the Linux-audio-dev mailing list