[FFmpeg-devel] [PATCH 212/217] avcodec/snow: Fix race in ff_snow_common_init()

[Michael Niedermayer]

On Wed, Dec 02, 2020 at 05:22:39AM +0100, Andreas Rheinhardt wrote:
> Commits d49210788b0836d56dd872d517fe73f83b080101 and
> ee8ce211ead04c8684da0c9c143814e57e9b9eda set the
> FF_CODEC_CAP_INIT_THREADSAFE flag for the Snow encoder resp. decoder;
> yet these codecs init functions aren't threadsafe at all:
> ff_snow_common_init() initializes static data, but there is no check
> at all that it is only done once by one thread.

These commits originated from long ago when it was felt that writing
the same value in the same location by 2 threads and always writing that
value in a thread before the same thread read it would not qualify
as undefined behavior or a race.
The current C standard makes it UB (to the best of my knowledge) 
so your change is correct but i think your commit message:
"aren't threadsafe at all" is suggesting a major issue which i think
this is not.
That said, is there any case known where code like this produces unexpected
behavior on any real platform with any real compiler ? (not counting
thread saftey check tools detecting / aborting)
For most undefined behavior cases i can think of some optimization
messing up or something but in this case everything i could think of
requires some rather odd hypothetical hardware ...

thx

[...]
-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Those who would give up essential Liberty, to purchase a little
temporary Safety, deserve neither Liberty nor Safety -- Benjamin Franklin
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 195 bytes
Desc: not available
URL: <https://ffmpeg.org/pipermail/ffmpeg-devel/attachments/20201202/aaec7350/attachment.sig>