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

Michael Niedermayer michael at niedermayer.cc
Wed Oct 21 08:50:38 CEST 2015

On Tue, Oct 20, 2015 at 04:57:49PM -0700, Dale Curtis wrote:
> Minor waste and more annoyingly triggers race detectors when the
> re-initialization happens across multiple threads. cos(0) == 1 and by
> default statics initialize to 0, so this check is safe.
> Signed-off-by: Dale Curtis <dalecurtis at chromium.org>
> ---
>  libavcodec/fft_template.c | 2 ++
>  1 file changed, 2 insertions(+)
> diff --git a/libavcodec/fft_template.c b/libavcodec/fft_template.c
> index 23ea453..2165ed0 100644
> --- a/libavcodec/fft_template.c
> +++ b/libavcodec/fft_template.c
> @@ -92,6 +92,8 @@ av_cold void ff_init_ff_cos_tabs(int index)
>      int m = 1<<index;
>      double freq = 2*M_PI/m;
>      FFTSample *tab = FFT_NAME(ff_cos_tabs)[index];
> +    if (tab[0])
> +        return;

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

Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Old school: Use the lowest level language in which you can solve the problem
New school: Use the highest level language in which the latest supercomputer
            can solve the problem without the user falling asleep waiting.
-------------- 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/20151021/3b0f98be/attachment.sig>

More information about the ffmpeg-devel mailing list