[wdmaudiodev] AW: Re: AW: Re: Possible problem in IPortDMus::Notify and servicegroup dispatching?

  • From: "Tobias Erichsen" <erichsen@xxxxxxxxxxxxx>
  • To: <wdmaudiodev@xxxxxxxxxxxxx>
  • Date: Mon, 16 Aug 2010 15:00:02 +0200

Hi Evert,

> This is indeed an annoying problem and probably easy to fix if you
have the source code of PortCls. But somehow I doubt
> that is going to happen. Is PortCls even supported still? I know that
Microsoft pulled the plug for DirectMusic some time ago.

AFAIK the PortCls is still part of the complete audio-framework up to
Windows 7, so I hope it is still supported ;-)

> The problem is not with IAllocatorMXF::PutMessage() or
IAllocatorMXF::GetMessage(). My Syser aided investigation showed that
> the deadlock occurs AFTER you return to PortCls from
IMXF::PutMessage() on a capture filter.

That was also what I figured, but apart from this current
freezing-issue, I was still wondering if it is safe to call PutMessage
on the Allocator of the IPortDMus within The PutMessage() of the
render-stream for example.

It is done in the sample, so I would consider it safe (but we all know
that there have been locking-issues in early versions
of the sample - hence the split into PutMessage and PutMessageLocked ;-)

And the same question goes for the capture-stream: can I call GetMessage
and PutMessage on the Allocator of the IPortDMus while
holding my private locks to secure my internal fifo?

> My guess about what happens is this: IMXF::PutMessage() is called on a
capture filter to retrieve MIDI data from it. It is a
> response to calling IPortDMus::Notify() on your capture port. PortCls
will continue to call IMXF::PutMessage() until that
> function returns NULL, meaning there is no more data.

I thought that the PutMessage returns an NTSTATUS - what result-code
would tell the PortCls to call me again? 

> The processing that PortCls does after receiving data from
IMXF::PutMessage() needs to acquire two spinlocks. About the same
> time IPortDMus::Notify() needs to acquire the same two spinlocks but
in reversed order; a classic deadlock scenario.
> The important thing in the above sentence is that, if there is no data
returned from IMXF::PutMessage() there will be no
> processing and hence no need to acquire the spinlocks. That is why my
solution will work; because there will be no new
> IPortDMus::Notify() call until IMXF::PutMessage() returns NULL.

But would not the race-condition persist?  When the last thing you do in
your PutMessage method is to reset a state-variable
to "not running anymore", you return and at that point PortCls will do
the PostProcessing with the necessity to lock ist
Spins and at the same time the place where you call the Notify() will
also know that the "not running anymore" is true and
issue a Notify?

> However, I tested this extensively with MidiTest (another one of those
indispensible tools ;))

I really love this tool - used it to test my driver (together with
MIDI-OX) extensively. 

> So, don't worry!

Unfortunately I'm the worrying kind ;-)


WDMAUDIODEV addresses:
Post message: mailto:wdmaudiodev@xxxxxxxxxxxxx
Subscribe:    mailto:wdmaudiodev-request@xxxxxxxxxxxxx?subject=subscribe
Unsubscribe:  mailto:wdmaudiodev-request@xxxxxxxxxxxxx?subject=unsubscribe
Moderator:    mailto:wdmaudiodev-moderators@xxxxxxxxxxxxx


Other related posts: