[Libav-user] Using the libav* libraries in a thread-safe manner?

Bruce Wheaton bruce at spearmorgan.com
Wed May 15 18:19:39 CEST 2013


On May 15, 2013, at 9:13 AM, Joe Flowers wrote:

> Carl and Hendrik,
> 
> Thank you very much for your comments and expertise.  
> 
> You are right, I'm mixing up thread-safety and re-entrantcy.  Sorry.
> 
> With Hendrik's advice on not cancelling threads to prevent a deadlock or zombie-type threads, I'm now more concerned with thread-safeness.

You're heading pretty far down a tangent with malloc etc. System calls won't be your problem.

Assuming you're using pthreads (or the windows equivalent), the main thing you need to worry about is the few ffmpeg functions that aren't re-entrant, mainly codec opening, selection and closing. Each context you open is as thread-safe as you make it, and you definitely don't need to wrapper all ffmpeg calls.

Look for the lock manager stuff, or put your own critical section around the non re-entrant functions. That's about it. On a modern OS, trying to second guess threading on the system libraries is a folly.

Bruce


> 
> 1.
> I know when I configure and make FFMPEG, there is an "--enable-pthreads" option. If I am understanding things correctly, this particular option is not relevant to the thread safety of a C program calling the libav* APIs, correct?
> 
> 2.
> I am using gcc on Ubuntu to compile and link to the libav* libraries and am wondering if I need to use a particular "-pthreads" option (or something else) with gcc to make sure I am using thread-safe C libraries to get a thread-safe malloc()?   The reason I ask is because in Windoze one has to link with the mulithreaded C libraries (*MT.lib) to get a thread-safe version of malloc().
> 
> Thanks!!!
> 
> Joe
> -------------------
> 
> 
> 
> 
> 
> 
> 
> 
> On Wed, May 15, 2013 at 11:37 AM, Carl Eugen Hoyos <cehoyos at ag.or.at> wrote:
> Joe Flowers <joe.flowers at ...> writes:
> 
> > I need to use the libav* APIs (specifically the audio
> > codecs) in a thread-safe way, but they seem to be full
> > of malloc()s and free()s which aren't re-entrant.
> 
> My malloc manual says that it uses mutexes "internally to
> protect the memory-management data structures employed by
> these functions" (alloc, free, etc.) to avoid corruption.
> Or do I miss something?
> 
> Audio codecs generally don't use multi-threading and
> should therefore not require special treatment.
> 
> Carl Eugen
> 
> _______________________________________________
> Libav-user mailing list
> Libav-user at ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/libav-user
> 
> _______________________________________________
> Libav-user mailing list
> Libav-user at ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/libav-user

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://ffmpeg.org/pipermail/libav-user/attachments/20130515/f45d6441/attachment.html>


More information about the Libav-user mailing list