Re: Deadlock when querying custom interface



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.



.



Relevant Pages

  • Re: DMO as a source filter
    ... I need to communicate to the DMO from the application in real ... Based on this in the docs for the DMO Wrapper filter I do not think you can ... "Streaming: The filter uses the IMemInputPin interface to handle all ...
    (microsoft.public.win32.programmer.directx.video)
  • DirectShow base classes and the possible deadlocks
    ... CBaseFilter::Pause locks the filter lock (okay, it's recursive locking, ... twice and release them ... stop the filter, so the lock is recursively acquired, and the deadlock never ...
    (microsoft.public.win32.programmer.directx.video)
  • Re: [Linux-cluster] Re: GFS, whats remaining
    ... >> inotify did that for a while, but we ended up going with a straight syscall ... it looks like we can agree on the core interface. ... I also implemented dlm_migrate_lockres() to explicitly remaster a lock ... Looking at the misc device that gfs uses, it seems like there is pretty ...
    (Linux-Kernel)
  • Re: Mysteriously invincible process
    ... Patty O'Dors wrote: ... > The interface doesn't lock - it stays responsive as if I have put it in ... > easier to kill it - as I will have an explicit object reference to the thread ...
    (microsoft.public.dotnet.languages.csharp)
  • Re: Lock/Unlock of ATL object from client
    ... ISerial has a Lock() ... This Lockfunction would return an interface pointer to an object ... and the second for whatever methods/properties require locking. ... its methods to the underlying serial object. ...
    (microsoft.public.vc.atl)

Loading