[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