On Tue, 22 Nov 2016 23:57:15 +0100 Michael Niedermayer <mich...@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 > > <mich...@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 > > [...] > _______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
