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

[Aaron Colwell]

Hi,

Some recent changes to Chromium unit tests have caused FFmpeg decoding to
get regularly scrutinized by our
ThreadSanitizer<http://www.chromium.org/developers/how-tos/using-valgrind/threadsanitizer>
tool.
This has led to the detection of a variety of race
conditions<http://code.google.com/p/chromium/issues/detail?id=93932>
in
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
them?
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?

Thanks,
Aaron