[FFmpeg-devel] [PATCH] avcodec/utils: use a default lock manager that uses a spinlock

[Reimar Döffinger]

On 18.10.2013, at 14:17, wm4 <nfxjfg at googlemail.com> wrote:
> On Fri, 18 Oct 2013 08:41:36 +0200
> Reimar Döffinger <Reimar.Doeffinger at gmx.de> wrote:
> 
>> Pthreads is not always available, and even if it is there is no guarantee it will be compatible with the threading system the application uses.
> 
> Well, ffmpeg is doing the multithreading, so of course pthreads will be
> available?

"The multithreading"? None of this is required or in any way relevant for the FFmpeg internal threading.
So no, pthreads might not be available, or FFmpeg might have been compiled without threading support.

> Why should there be any "compatibility" be necessary? As far as I can
> see, ffmpeg will always use the system's standard threading API, so
> what exactly is the problem?

There have been pthread implementations that could not "see" the native threads (as a stupid example, a generic pthread implementation based on cooperative scheduling which only uses one single native thread). In those cases a pthread lock will fail to affect the applications native threads, i.e. the lock will simply not work for threads not created by pthreads.
There are many variants of this.
There is no general way to know if the applications threading method is compatible with what FFmpeg used, which is the reason to have the lock manager in the first place.