[Ffmpeg-devel] alsa input / output

Måns Rullgård mans
Sun Mar 25 12:50:09 CEST 2007


Reimar D?ffinger <Reimar.Doeffinger at stud.uni-karlsruhe.de> writes:

> 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.

The same thing happens with signal handlers.

-- 
M?ns Rullg?rd
mans at mansr.com




More information about the ffmpeg-devel mailing list