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

  • From: "Tobias Erichsen" <t.erichsen@xxxxxx>
  • To: <wdmaudiodev@xxxxxxxxxxxxx>
  • Date: Mon, 16 Aug 2010 07:15:08 +0200

Hi Evert,

thanks for your feedback... 

> I have seen this exact behaviour in my own driver and for 
> months I couldn't figure out what was wrong. It only happened 
> on multi-processor or hyper-threaded machines, so it was 
> obviously caused by something deadlocking. The symptoms were: 
> complete system freeze at random moments.
> Only hard-reset would help.

It seems that other people (especially those with virtual MIDI
drivers that support multiple virtual ports) have this problem
as well.  

> I went through my code over and over again but couldn't find 
> anything wrong.
> Like you I also suspected IAllocatorMXF::PutMessage(). In the 
> end I used Syser to track down the problem (where would we be 
> without Syser? Ok, it's not perfect, but I couldn't have 
> fixed this without it).

A clarification from Microsoft whether IAllocatorMXF::PutMessage()
and IAllocatorMXF::GetMessage() can be used while holding a lock
would be nice - especially since the DMusUart sample does so for
PutMessage() in the ConsumeEvents method, but others on this
mailing-list warn (with good cause) to call OS-functionality
while holding a lock - but implementing SourceEvtsToPort and
ConsumeEvents without holding a lock could be a complete
> I also found IPortDMus::Notify() to be the culprit. Of course 
> it's hard to provide irrefutable evidence but I'd say this 
> qualifies as a system bug.

I would hope that the Microsoft guys on this list will participate
in this discussion and help resolve this issue.
> What solved it for me is to minimize the IPortDMus::Notify() 
> calls. I use some sort of flag for indicating that the port 
> has been notified which will only be reset after the queue 
> has been emptied.
> For as long as the flag is set I don't call 
> IPortDMus::Notify() anymore, since I know that queue 
> processing will continue anyway.

Good if this clears up the problem for you, but I'm a bit uneasy
with this approach since I would always doubt if a freeze could
not come up under other conditions (more concurrent virtual ports,
more CPUs, other system-load, more port-throughput).

So I'd consider a "real" solution for this issue in the PortCls
to be appropriate.

I hope some other people with experience could chime in on this
subject as well...

Best regards,


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: