[FFmpeg-devel] Race conditions in libavcodec/pthread.c

Aaron Colwell acolwell at chromium.org
Thu Aug 25 20:26:09 CEST 2011


Some recent changes to Chromium unit tests have caused FFmpeg decoding to
get regularly scrutinized by our
This has led to the detection of a variety of race
libavcodec/pthread.c . Quick inspection of the code reveals that there is
significant use of the "double-checked locking" anti-pattern and
inconsistent use of PerThreadContext::mutex and
PerThreadContext::progress_mutex which are likely causing of most of the
race conditions. I wanted to ask a few questions before jumping in and
trying to fix this.

1. Are you already aware of these issues?
2. Is someone already working on fixing these?
3. Who is the expert on libavcodec/pthread.c so I can direct questions to
4. Why is "double-checked locking" being used? Will there be significant
protest if I remove it?
5. What is the relationship between PerThreadContext::mutex
& PerThreadContext::progress_mutex and what member variables are they
supposed to protect? I've seen cases where only mutex is held, mutex &
progress_mutex are held, and only progress_mutex is held. At times these 3
cases appear to modify the same state variables. ThreadSanitizer is getting
stuck on some test runs now which leads me to believe that there is a
locking pattern that results in deadlock.
6. Is someone else interested in tackling this?


More information about the ffmpeg-devel mailing list