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

[Michael Niedermayer]

On Fri, Oct 18, 2013 at 08:41:36AM +0200, Reimar Döffinger wrote:
> 
> 
> On 18.10.2013, at 01:47, Michael Niedermayer <michaelni at gmx.at> wrote:
> >> 2. Use pthreads, and on Windows, one of the popular pthreads wrappers.
> > 
> > Last time this idea came up someone said it doesnt work because
> > theres no gurantee that the pthread mutex you then use is compatible
> > with the threads its trying to sychronize which may be something
> > else than pthread based. IIRC
> 
> To be honest, neither of these approaches work properly.
> Your atomics approach will completely break (as in cause hangs) in an environment using cooperative scheduling if the user yields in a FFmpeg callback.

i hoped that such platforms dont exist anymore


> It also will burn the CPU for a whole time-slice in single-core environments if there is any congestion.

that sounds nasty but if theres congestion (which for the cases where
it would be used i would not expect) you sure prefer burning cpu over
it somehow mysteriously failing in hard to reproduce ways.


> Note these also apply to the av_log changes.

the second patchset doesnt have the lock over the user callback but
just the default, so the question would be if any function in there
can cause a "cooperative schedulin environment" to yield


> 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.
> Or in short: we don't do it currently, because it simply doesn't work in general.
> Whether we should support (either by default or with a simpler way that requires less code) a pthreads based application is a different question, but it's likely to break some use case, and probably needs to be considered and API change.

You miss a problem here
the current code does not work, its not that my patches implement
merely a convenient default ...

the lock manager registration itself is completely unsafe
consider 2 libs or an application with plugins, or an application
and a lib
loading libavcodec & libavformat or in case of 2 libs libavcodec twice
how could they set a lock manager ? each might require a different
lock manager and even if they use the same the registration still
is not thread safe as it would unregister the old at a random non
synchronized point.
And to make it worse the 2 libs/app using libavcodec could use
different thread systems 

considering above iam not sure the spinlock (in environments where its
safe) would be that bad of a solution.
but iam happy to implement something else

[...]

-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Breaking DRM is a little like attempting to break through a door even
though the window is wide open and the only thing in the house is a bunch
of things you dont want and which you would get tomorrow for free anyway
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: Digital signature
URL: <http://ffmpeg.org/pipermail/ffmpeg-devel/attachments/20131018/cfa52b2d/attachment.asc>