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
signature.asc
Description: PGP signature
_______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
