[FFmpeg-devel] [PATCH] avcodec/utils: use a default lock manager that uses a spinlock
michaelni at gmx.at
Fri Oct 18 01:47:24 CEST 2013
On Fri, Oct 18, 2013 at 12:01:55AM +0200, wm4 wrote:
> On Thu, 17 Oct 2013 15:40:36 +0200
> Michael Niedermayer <michaelni at gmx.at> wrote:
> > That makes avformat & avcodec thread safe without the need to explicitly
> > register a lock manager.
> So what again is the reason that you can't do one of these things:
> 1. Don't use global state, but recreate it every time the user creates
> a demuxer or whatever. So there's nothing to synchronize.
we where always trying to avoid code that initialized globals
in thread unsafe ways.
so yes we & i are / am trying that sort of since a while and most
code shuld just dumbly init the tables on every init and always write
the same data to each byte, making them inherently safe ...
also there are cases where global state just exists and
synchronization simply is needed.
the codec/format/filter/parser/... registration
some external libraries which are not thread safe themselfs
some APIs which are not thread safe (parts of OpenCL IIRC fall in this
> 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
> I figure it's not quite as simple as it looks like, but badly
> reimplementing the operating system/libc provided locking primitives
> doesn't sound like a nice solution at all.
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
Why not whip the teacher when the pupil misbehaves? -- Diogenes of Sinope
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 198 bytes
Desc: Digital signature
More information about the ffmpeg-devel