[FFmpeg-devel] [PATCH] avcodec thread safety fix

Art Clarke aclarke
Sat May 30 05:03:30 CEST 2009


> Well, my path does
>
> if(cb(&codec_mutex, AV_LOCK_CREATE))
> ? ? return -1;
>
> In the callback register function. I believe that should be enough?

Sorry, I missed that.  You were already doing what I suggested.  You
should create the mutex AFTER you set ff_lockmgr_cb to avoid a race.

e.g. imagine the callback created a mutex but also started a new
thread that immediately tried to open a codec before the first
callback returned.

> Perhaps it could AV_LOCK_DESTROY all global mutexes if you invoke
> ff_lockmgr_register with NULL. Or have av_lockmgr_unregister()?

That would be useful.  I prefer av_lockmgr_register(null) since it
operates more like the other callbacks then.  Please call unlock
BEFORE you unregister the callback and set the new callback (i.e.
always make sure when you're setting or destroying a lock with a lock
manager, that it's the manager actually set on ff_lockmgr_cb when
running).

> This sounds reasonable to me. It would also make it possible to avoid
> locking for codecs that don't need it at all.

As Michael pointed out, this is, um, complicated.  I'd only suggest
going down this path if this was a real scaling problem for a real
world use case of libav (an aside, I'd be very surprised if contention
for the global codec open  lock was the biggest scaling problem in
someone running a multi-threaded decoder/encoder -- and I'm talking
from the perspective of someone who already does exactly that).   I
mentioned it as an idea, but I'll supplement by saying "it's an idea
awaiting the problem" :)

- Art


-- 
http://www.xuggle.com/
xu?ggle (z?' gl) v. To freely encode, decode, and experience audio and video.

Use Xuggle to get the power of FFMPEG in Java.



More information about the ffmpeg-devel mailing list