[gst-devel] possible optimisations in pad_push mutex handling

[Gruenke, Matt]

-----Original Message-----
From: Wim Taymans [mailto:wim.taymans at gmail.com] 
Sent: Monday, October 11, 2010 04:20
To: Discussion of the development of GStreamer
Subject: Re: [gst-devel] possible optimisations in pad_push mutex
handling

<snip/>

> Yes, it would be very interesting. I've been looking at how to do this
> for a while now. Unfortunately, most ideas involve making the object
> flags and the signal counters atomic (which is something I don't think
> We can do safely for 0.10).

I like the idea of optimizing the general case.  Would it be possible to
use some sort of hierarchical locking scheme - where a streaming thread
wouldn't grab lower-level locks if it could lock the entire pipeline
segment?

One aspect of locking to watch out for is normal mutexes that are held
for most of the time.  I ran into a case, on Linux 2.6, where the thread
holding the lock was running at significantly higher priority.  The OS
did not preempt the first thread, when it released the mutex, even
though other threads were blocked on obtaining it.

I think the solution might be to use a different type of mutex (e.g.
read/write).

<snip/>

> Or maybe add less contention to the glib type lookups.. Or
> maybe improve some of the element processing functions.

That would sure be nice!

<snip/>


Matt