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

[wm4]

On Fri, 18 Oct 2013 18:20:20 +0200
Reimar Döffinger <Reimar.Doeffinger at gmx.de> wrote:

> 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.

If no threading implementation is available, you can just assume that
the target platform doesn't have threads, or if it does, that it's in
the user's responsibility to compensate for the lack of porting.

Or in other words: ffmpeg properly ported to a platform should either
1. use the platform's threading API, either directly, or via libpthread,
2. or assume there is no threading at all.

Everything else is insane. You don't need to make everything worse for
everyone just because someone decides he wants to do insane things.

> > 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.

How is this not complete non-sense? Is every library that needs
internal locking supposed to have such a "lock manager"? ffmpeg sure is
the first library I've seen that does this.

Do you have an example for a non-theoretical platform where your
assumption holds up?

I'm not entirely sure why a threading implementation would need to know
("see") about a thread just for locks if the underlying primitives
(i.e. syscalls) are the same anyway. Are you thinking about a case
where cooperative scheduling and kernel threads are somehow mixed? Why
would ffmpeg need to have to support such a broken setup?

> 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.

You've got to make some reasonable assumptions about your platform, or
you enter hell. And again, I haven't heard of a real-world example yet
where a lock manager is really needed, and also where you couldn't
decide this at compile time.