Re: Deadlock when querying custom interface
- From: Jeremy Noring <kidjan@xxxxxxxxx>
- Date: Thu, 16 Jul 2009 12:58:18 -0700 (PDT)
The *correct* way is the *least* amount of locking that is threadsafe.
On Jul 16, 9:48 am, "Aviad Rozenhek <avia...@xxxxxxxxx>"
<avia...@xxxxxxxxx> wrote:
I'm developing a custom transform filter which supports a custom
interface, lets call it the ICalcThingies interface
I'm querying this interface from the application, in order to get some
internal statistic which is calculated in the filter's ::Transform()
function.
First, if you're using CTransformFilter, you don't need to worry about
this that much (i.e. "The CTransformFilter and CTransInPlaceFilter
base classes handle many of the issues described in this article. If
you are writing a transform filter, and your filter does not wait on
events inside a streaming method, or hold onto samples outside of
Receive, then these base classes should be sufficient.") You need a
completely separate lock to make sure CalcThingies and your Transform
method don't step on each other's toes; other than that, you don't
need to worry about Application/Streaming locking at all.
Are you waiting on events inside a streaming method, or holding onto
samples outside of receive?
for instance, if I remove the filter lock, it means that the internal
state of my thingies is guarded by the streaming lock
so that if I mess with this internal state in a pause, flush or other
operation, I would need to acquire the streaming lock there.
basically it would mean that my implementation of Pause() would be
Does CalcThingies need to change the state of the filter? If not, why
are you using the filter lock? Does CalcThingies interact with the
streaming thread? If not, why are you using the filter lock? Does
CalcThingies need to hold _both_ locks at the same time? If not, why
are you taking both of them? Again, your problem is you're probably
locking when there is no good reason to do so. That is the
*incorrect* way to do it. (also, you should limit the scope of your
autolocks--I see you're claiming them at the beginning of your
methods. I typically put them inside a set of {} to have the autolock
go out of scope, and limit the time I spend locked as much as
possible)
Maybe I don't fully understand your problem, in which case maybe you
could explain in more detail what your graph looks like, and what
you're trying to do, but I have plenty of filters with custom methods
that do exactly what you're doing (i.e. I want to access something
produced by Transform() method), I use a single lock, and it works
just fine.
.
- References:
- Deadlock when querying custom interface
- From: Aviad Rozenhek <aviadr1@xxxxxxxxx>
- Re: Deadlock when querying custom interface
- From: Jeremy Noring
- Re: Deadlock when querying custom interface
- From: Aviad Rozenhek <aviadr1@xxxxxxxxx>
- Re: Deadlock when querying custom interface
- From: Jeremy Noring
- Re: Deadlock when querying custom interface
- From: Aviad Rozenhek <aviadr1@xxxxxxxxx>
- Deadlock when querying custom interface
- Prev by Date: Re: problem with dircectshow
- Next by Date: Re: CoCreateInstance returns 0x8007007f - procedure could not be found
- Previous by thread: Re: Deadlock when querying custom interface
- Next by thread: H.264 media types
- Index(es):
Relevant Pages
|
Loading