[gst-devel] INCSCHED1: scheduling / threading branch of GStreamer

[Tim 'Tool-Man' Taylor]

I see the light :)

Case 1 is deadlock, no liberty taking necessary.

Matt Howell wrote:

> i should have spent more time on my initial response.  you're correct:
> none of these are race conditions.  basically i don't like the term
> "liveness" -- but that's not important.  "Liveness Problems..." is fine
> and correctly describes all the scenarios.
> 
> fyi, i consider case 1 deadlock because:
> + B waiting for A to wake it up (with data)
> + A waiting for B to wake it up (that B executed change state)
> => (taking some liberty) the deadlock condition is
>    "i'm waiting for you to wake me up"
> this is not 100% correct because the real conditions are different --
> "data" vs "changed state" -- but i've always considered this deadlock.
> 
> matt.
> --
> Tim 'Tool-Man' Taylor wrote:
> 
> 
>> Now, you're probably going to think I'm trying to pick a fight :)  ...
>> 
>> Unless I've misunderstood one of the scenarios (a distinct possibility)
>> a more accurate heading would be: "Liveness Problems and Proposed
>> Solutions".
>> 
>> I don't see how they are race conditions, either.  It's tempting to
>> think of deadlock as a type of race condition, but typically the term
>> "race condition" is reserved for describing code that relies on
>> scheduling to keep other threads from accessing objects in intermediate
>> (i.e. inconsistent) states.
>> 
>> I don't mean to be pedantic.  However, my C-fu is minimal and my
>> concurrent C programming skills are non-existent, so I can't divine
>> understanding by perusing the code...at least not easily.  The higher
>> level documentation and notes are how I grok gstreamer right now.
>> 
>> I'm /not/ saying these scenarios don't have deadlock or race conditions.
>>   I'm saying "I don't see them".  That may mean they aren't there.  More
>> likely it means means I lack the understanding of gstreamer internals to
>> "see" them based on your notes.  This is probably fine.  Your notes were
>> intended for internal developers, not for gstreamer groupies like me :)
>> 
>> --
>> Tim Taylor
>> tim at tool-man.org
>> 
>> _______________________________________________
>> gstreamer-devel mailing list
>> gstreamer-devel at lists.sourceforge.net
>> http://lists.sourceforge.net/lists/listinfo/gstreamer-devel
> 
> 
> 
> _______________________________________________
> gstreamer-devel mailing list
> gstreamer-devel at lists.sourceforge.net
> http://lists.sourceforge.net/lists/listinfo/gstreamer-devel


-- 
Tim Taylor
tim at tool-man.org