[Ffmpeg-devel] alsa input / output

Reimar Döffinger Reimar.Doeffinger
Sun Mar 25 12:45:29 CEST 2007


Hello,
On Sun, Mar 25, 2007 at 12:21:57PM +0200, matthieu castet wrote:
> Reimar D?ffinger wrote:
> >On Sun, Mar 25, 2007 at 05:26:16AM +0200, Michael Niedermayer wrote:
> >>>I should also note that such a lock-free implementation depends on
> >>>volatile keyword working "well enough" and pointer reads and writes being
> >>>atomic on the architecture...
> >>could you show one example where volatile makes a difference in practice?
> >
> >In practice maybe not, but in theory you could do
> >while (av_fifo_size(f) <= 0) sleep();
> >and the compiler might inline av_fifo_size (not gcc though unless we
> >move it into fifo.h one time) and without volatile that could be converted 
> >to
> >if (av_fifo_size(f) <= 0) while (1) sleep();
> >Actually a compiler could do this even without inlining as long as it
> >can find out that av_fifo_size has no side effects (it does not modify
> >anything besides its return value) and does not depend on volatile data.
> Do you have a better example, because AFAIK pointer are considered as 
> volatile data ?

Well, if it doesn't have to be related to fifo.*, for simple interrupt
handling in microcontrollers it is important.
This is of course far from ffmpeg, but on normal PCs the examples are
just not as obvious and simple...
Like you have a button connected to an hardware interrupt.

volatile char press;

// interrupt handler
void isr(void) {
  press = 1;
}

void main(void) {
  while (1) {
    if (we_want_to_wait_for_button_press) {
      press = 0;
      while (!press) {
        // some simple code, does not change press variable
      }
    }
    // some other code
  }
}

Without the volatile even gcc -O2 would optimize the while (!press) to a
while (1) -  yes, that actually happened to me.
For this simple code we could do this without hardware interrupt by
periodically checking the input where the button is connected, but that
gets very complicated if e.g. in "// some other code" you want to do
slow serial communication and at the same time wait for a button press,
you will most likely miss presses sometimes...

Greetings,
Reimar D?ffinger




More information about the ffmpeg-devel mailing list