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

[Juhana Sadeharju]

>From: Joshua Haberman <joshua at reverberate.org>
>
>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 

One could use plain variables for the VU values.
Engine updates them. And GUI reads them. GUI may not
get all values, but the most important temporary max level
changes so slowly that GUI does not skip on that.

Another choise is to resample the VU signals to low enough rate
in the engine. If 30 frames per second is the display refresh
rate, then using rate 20 Hz for VU signals allows GUI to catch
up if VU freezes.

>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

What it means practically? Any code? (Cannot check wikipedia now.)

One could write some ID numbers to the buffer next to the buffer
pointers. If the ID number is not what it should, then the problem
has been recognized. What to do in this situation? If it is
a non-realtime thread (disk thread), the disk thread could idle
a bit or do something else. But if it is the realtime audio thread,
then what? Any this kind of trickery could be slower than any
memory barriers, guess.

Quick question: disk thread may suspend if there are no disk use.
How the disk thread is woken up to read the lock-free buffer?
Are the following yes or no?
(1) audio thread sends SIGCONT signal to disk thread,
(2) audio thread sends sys/msg.h message to disk thread,
(3) audio thread sends one byte via a pipe to disk thread,
(4) disk thread uses timer to wake up itself.
Something else?

Audio thread sends the wake up relatively rarely. So, if pipe has
a small buffer, then pipe could be practically lock-free. How it is?

Juhana