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

[Michael Niedermayer]

Hi

On Sat, Mar 07, 2009 at 07:09:28PM +0100, Reimar D?ffinger wrote:
> 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.

There are more cases where problems can appear in theory
for example with a full buffer

on the consumer side:
the write to the pointer might end up being executed before the reading
and thus on the producer side data might be overwritten before it is read
by the consumer.

i agree this is a little theoretic because the correct behavior is a detected
buffer full condition and droping of data still its non deterministic
behavior.


> In addition it would seem reasonable if the C compiler would take care
> of this issue by itself when using "volatile" variables.

yes but i very seriously doubt gcc does this, especially as at least for
x86 the needed instructions are only availabe since some more recent
cpus, I suspect ppro but it might have been aother one.


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

I was wondering if that could actully fail on any supported cpu?


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

I guess it cant hurt to put empty macros where the barriers should be,they
can always be filled later if someone wants ...

[...]
-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Let us carefully observe those good qualities wherein our enemies excel us
and endeavor to excel them, by avoiding what is faulty, and imitating what
is excellent in them. -- Plutarch
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
URL: <http://lists.mplayerhq.hu/pipermail/ffmpeg-devel/attachments/20090307/4f7f09f8/attachment.pgp>