On Wed, Oct 21, 2015 at 6:52 PM, Dale Curtis <dalecur...@chromium.org> wrote:
> On Tue, Oct 20, 2015 at 11:50 PM, Michael Niedermayer < > mich...@niedermayer.cc> wrote: >> >> the last element to be written should be checked, so that if >> initialization is done by 2 threads at the same time, neither can >> return from this function without initialization having finished >> >> also the race detectors are broken if they complain about cases where >> a variable that has value a is set to value a, that cannot be part of >> a race, not even if a is written byte per byte instead of atomically >> unless theres something iam missing >> Is this something that can be fixed or disabled on the side of the >> race detectors? >> It might reduce false positives in FFmpeg and potentially other >> tools. >> > > We can suppress it, which I think is more reasonable then the overhead > it'd take to make this "race" go away. I notice the sin tables are > initialized within the fft context so there's no "race." Is there a reason > the cosine tables aren't done this way? > Actually it looks like sin may suffer from the same issues -- it doesn't make a copy like I was thinking it did. One of the TSAN folk detailed why suppression isn't a good idea here https://codereview.chromium.org/1412123007/#msg7 -- which roughly says we can't rely on the compiler to do the right thing here. What are your thoughts about using ff_thread_once() to build the full sin and cos tables all at once? - dale _______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
