Re: my action item for explaining semantics of notify callbacks in SCE-MI pipes

Hi Shabtay,

> BTW, I assume we are meeting tomorrow which will give us an opportunity 
> to dive deeper into this. Are you going to dial in?

I am still not quite sure what our new meeting schedule is.  Hmm . . .

> I believe that your proposal is that the callbacks are called each time 
> that an element has moved as a result of a call.

I don't think the intention is that there is a one-to-one correspondence
between callback invocations and elements.  That would be inefficient.
If the consumer removes N elements in one operation, only one callback
should result in an efficient implementation.  I am not sure the spec
actually prevents an implementation from invoking the callback more
than once in this scenario, but it would not be the most efficient
thing to do.

> Does your proposal allow the infrastructure to yield control from the 
> HDL side to the SW side under any other condition?

How about when the buffer implementing the pipe is full?

> [Shabtay] Just confirming what you say, you are proposing that "OK to 
> send" will be notified 100 times if the try_receive() moved 100 elements 
> from the pipe. But the consumption of the 100 elements per se will not 
> cause the consumer to yield control to the producer.

I don't see how you conclude this is the case.  That would be
inefficient.  One callback should be sufficient to get the software
side woken up and start producing more elements.

> [Shabtay] I hope the above clarifies, but in a nut shell do you agree 
> that N callbacks happening before the yield occurs creates the same 
> effect as one callback when the yield occurs?

That would depend on what the callback function did.  If it had
side effects it may result in different behavior.  The simplest
example I can think of is a counter that is incremented, e.g., to
keep track of some sort of time out.  We may have to warn users
not to do such things.

Per



-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.