[FFmpeg-devel] [PATCH] Don't needlessly reinitialize ff_cos_## tables.

[Dale Curtis]

On Wed, Oct 21, 2015 at 6:52 PM, Dale Curtis <dalecurtis at chromium.org>
wrote:

> On Tue, Oct 20, 2015 at 11:50 PM, Michael Niedermayer <
> michael at 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