[FFmpeg-devel] [PATCH] avutil: fix data race in av_get_cpu_flags().
wm4
nfxjfg at googlemail.com
Wed Nov 23 01:30:05 EET 2016
On Tue, 22 Nov 2016 23:57:15 +0100
Michael Niedermayer <michael at niedermayer.cc> wrote:
> On Tue, Nov 22, 2016 at 02:00:12PM -0800, Wan-Teh Chang wrote:
> > Hi Michael,
> >
> > On Tue, Nov 22, 2016 at 1:22 PM, Michael Niedermayer
> > <michael at niedermayer.cc> wrote:
> > >
> > > ok, i see th race but do you really need the atomic operations ?
> > > isnt merging the 2 variables into 1 as you do enough ?
> > > (i mean the tools might still complain but would there be an actual
> > > race remaining?)
> >
> > The atomic operations avoid the "undefined behavior" resulting from
> > the data races in the C source code. ThreadSanitizer analyzes the C
> > source code, therefore it must warn about what may be undefined
> > behavior according to the C standard, even though for a particular
> > compiler and processor, the generated code is the same.
> >
> > Here is a small test program that shows gcc generates the same x86_64
> > assembly code for the normal and atomic (with relaxed memory ordering)
> > load and store operations:
>
> we have plenty of code that accesses fields without the extra layer
> of weak atomics.
> For example the progress code in the frame threading.
Which was recently fixed in Libav AFAIR...
>
> Can you just merge the varible ?
>
> this also would be easier to backport if anyone wants to backport
>
> If you still want to add weak atomics as in the patch, afterwards on
> top iam not against but that is me, i wont apply it if theres no
> consensus or clear majority in favour though
>
> [...]
>
More information about the ffmpeg-devel
mailing list