[FFmpeg-devel] [PATCH] libavdevice: JACK demuxer

[Reimar Döffinger]

On Sat, Mar 07, 2009 at 06:05:06PM +0100, Michael Niedermayer wrote:
> More specifically the update of the pointer/index that is performed after
> updating the buffer content may or may not be seen in that order by
> another CPU.

Yes, but that is only a problem if the consumer thinks data is available
before it actually was stored, and (for the audio playback case) unless
you are already very close to an empty audio buffer that can only happen
if the updates happen in the reverse order and with more than several
msec delay.
In addition it would seem reasonable if the C compiler would take care
of this issue by itself when using "volatile" variables.
Anyway, for the current use and in practice, I consider that an even
smaller issue than the assumption of 32-bit atomic reads and writes.
A good implementation would at least in addition provide a method that
avoids those issues though, e.g. by using the appropriate pthreads
functions (and hope that those are sufficient - not sure if they either
use memory barriers or otherwise avoid those issues or if they use the
ostrich algorithm because there are no issues in practice on the
supported systems).