[FFmpeg-devel] [PATCH] avutil: fix data race in av_get_cpu_flags().

Michael Niedermayer michael at niedermayer.cc
Wed Nov 23 00:57:15 EET 2016

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.

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


Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Complexity theory is the science of finding the exact solution to an
approximation. Benchmarking OTOH is finding an approximation of the exact
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 181 bytes
Desc: Digital signature
URL: <http://ffmpeg.org/pipermail/ffmpeg-devel/attachments/20161122/6009fed7/attachment.sig>

More information about the ffmpeg-devel mailing list