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

  • From: "Evert van der Poll" <evert@xxxxxxxxxxx>
  • To: <wdmaudiodev@xxxxxxxxxxxxx>
  • Date: Tue, 17 Aug 2010 12:32:17 +0100

Hi Tobias,

I noticed I made a mistake. I used IAllocatorMXF and IMXF as if it were the
same thing, but it's not.
IMXF is the interface your stream exposes to PortCls while IAllocatorMXF
only handles the pool of events. But I guess you still understood what I was
saying.

>> Though this only works under one assumption:

>> The ::PutMessage() on the drivers capture-stream must be called at
>> least one additional time by PortCls for the clearing to work,
>> otherwise we will get into a starvation situation since the producer
>> will never again call ::Notify()

How could it work otherwise? How else is PortCls to know that it has
retrieved all the data?


Evert




-----Original Message-----
From: wdmaudiodev-bounce@xxxxxxxxxxxxx
[mailto:wdmaudiodev-bounce@xxxxxxxxxxxxx]On Behalf Of Tobias Erichsen
Sent: Tuesday, August 17, 2010 7:14 AM
To: wdmaudiodev@xxxxxxxxxxxxx
Subject: [wdmaudiodev] AW: Re: AW: Re: AW: Re: Possible problem in
IPortDMus::Notify and servicegroup dispatching?


Hi Evert,

thanks again for your invaluable feedback...

> 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.

You are right of course - I have changed my code correspondingly
and the first results seem promising :-)

Though this only works under one assumption:

The ::PutMessage() on the drivers capture-stream must be called at
least one additional time by PortCls for the clearing to work,
otherwise we will get into a starvation situation since the producer
will never again call ::Notify()

So anyone from Microsoft listening in on this conversation?

Is this behaviour inherent in all current PortCls implementations
for the various OSs (XP -> W7, 32bit & 64bit)?
And can one expect this behaviour to persist in future updates?

Best regards,
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/

Other related posts: