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

  • From: "Tobias Erichsen" <t.erichsen@xxxxxx>
  • To: <wdmaudiodev@xxxxxxxxxxxxx>
  • Date: Tue, 17 Aug 2010 18:39:19 +0200

Hi Devendra,

thanks, I had already seen this and my driver is based on the later
(corrected sample).

This current issue has nothing to do with the render-path (which had been
the problem in the old sample), but rather a locking- hiearchy issue in the
capture-path of PortCls:

Invoking ::Notify on the service-group of the capture-path while the
capture-path is currently actively working on the DPCs will result in a
deadlock on XP SMP machines.

So a completely different scenario...

Best regards,
Tobias 

<sent again to the mailinglist, the first response errouneously went to
Devendra personally>

> -----Ursprüngliche Nachricht-----
> Von: AI Developer [mailto:developer@xxxxxxxxxxxxxxxx] 
> Gesendet: Dienstag, 17. August 2010 07:55
> An: wdmaudiodev@xxxxxxxxxxxxx
> Betreff: [wdmaudiodev] Re: AW: Re: AW: Re: Possible problem 
> in IPortDMus::Notify and servicegroup dispatching?
> 
> Puryear acknowledged it, and provided alternative code. The 
> original discussion was when this list was on Yahoo groups. 
> I'm not sure if you can access the group now - as it requires 
> membership.
> X-archive-position: 4925
> X-ecartis-version: Ecartis v1.0.0
> Sender: wdmaudiodev-bounce@xxxxxxxxxxxxx
> Errors-to: wdmaudiodev-bounce@xxxxxxxxxxxxx
> X-original-sender: developer@xxxxxxxxxxxxxxxx
> Precedence: normal
> Reply-To: wdmaudiodev@xxxxxxxxxxxxx
> List-help: <mailto:ecartis@xxxxxxxxxxxxx?Subject=help>
> List-unsubscribe: 
> <wdmaudiodev-request@xxxxxxxxxxxxx?Subject=unsubscribe>
> List-software: Ecartis version 1.0.0
> List-Id: wdmaudiodev <wdmaudiodev.freelists.org>
> X-List-ID: wdmaudiodev <wdmaudiodev.freelists.org>
> List-subscribe: <wdmaudiodev-request@xxxxxxxxxxxxx?Subject=subscribe>
> List-owner: <mailto:schulz.carsten@xxxxxxx>
> List-post: <mailto:wdmaudiodev@xxxxxxxxxxxxx>
> List-archive: <//www.freelists.org/archives/wdmaudiodev>
> X-list: wdmaudiodev
> 
> There is however a (badly formatted version) of the 
> discussion on freelists. Here is one link:
> 
> //www.freelists.org/post/wdmaudiodev/Problem-capturing-mi
> di-on-multiprocessor-SMP-XP-machines,2
> 
> Hope that helps.
> 
> Thanks.
> Devendra.
> 
> ps: If you need the better formatted version, please email me 
> off the list, and I'll copy paste from the Yahoo group archive.
> 
> On 8/17/10 4:19 AM, Evert van der Poll wrote:
> > Hi Tobias,
> >
> > Maybe I wasn't entirely clear.
> >
> >>> But would not the race-condition persist?
> > The MIDI data is returned by calling 
> IAllocatorMXF::PutMessage(), not 
> > by the return value from the function. That is right.
> > But if the queue is empty, the call to IMXF::PutMessage() 
> will return 
> > to PortCls without having submitted new data. PortCls will only call
> > IAllocatorMXF::PutMessage() after it has processed all 
> previous data. 
> > So in this last call it is safe to set your "not running anymore" 
> > flag, knowing that you already emptied your queue in the 
> previous call 
> > and that there is not going to be any processing on 
> PortCls's side since there is no new data.
> > There is no race-condition in this scenario.
> >
> >>> 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.
> > Actually I don't use a spinlock on my capture stream. If you look 
> > closely at the DDK sample you will see that it also doesn't use a 
> > spinlock there. The call to
> > SourceEvtsToPort() from the
> > PutMessageLocked() function is actually bogus. You won't call this 
> > from your DPC because that is handling your render stream. 
> The capture 
> > stream is entirely driven by PortCls.
> >
> > The only place where I call IAllocatorMXF::PutMessage() 
> while holding 
> > a spinlock is on my render stream. This looks safe to me. 
> You're only 
> > recycling a used event. There is not going to be any 
> processing on it 
> > on PortCls's side.
> >
> > Regards,
> > Evert
> >
> >
> >
> > -----Original Message-----
> > From: wdmaudiodev-bounce@xxxxxxxxxxxxx 
> > [mailto:wdmaudiodev-bounce@xxxxxxxxxxxxx]On Behalf Of 
> Tobias Erichsen
> > Sent: Monday, August 16, 2010 2:00 PM
> > To: wdmaudiodev@xxxxxxxxxxxxx
> > Subject: [wdmaudiodev] AW: Re: AW: Re: Possible problem in 
> > IPortDMus::Notify and servicegroup dispatching?
> >
> >
> > 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 ;-)
> >
> > Tobias
> > ******************
> >
> > 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
> >
> > URL to WDMAUDIODEV page:
> > http://www.wdmaudiodev.com/
> >
> 
> ******************
> 
> 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
> 
> URL to WDMAUDIODEV page:
> http://www.wdmaudiodev.com/
> 

******************

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

URL to WDMAUDIODEV page:
http://www.wdmaudiodev.com/

Other related posts: