Per, Shabtay, Comments ... Per Bojsen wrote: > 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. johnS: Correct. > If the consumer removes N elements in one operation, only one callback > should result in an efficient implementation. I am not sure the spec johnS: Correct. > 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. johnS: Actually with the new proposed wording, the spec is actually requiring the more efficient operation. Hopefully the wording removes any ambiguity but if it does not, I'm open to suggestions. I would like to propose that N calls for N elements is an incorrect implementation. And it certainly could lead to different application behavior so we don't want to allow for this. > >> 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? johnS: Precisely. i.e. a blocking function will see a try function fail due to a full (or empty) pipe and so will yield at that point. Until it can try again. Again, refer to the example in the spec for how this is done. > >> [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. johnS: Agreed. <eom> > >> [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 email may contain material that is confidential, privileged and/or attorney work product for the sole use of the intended recipient. Any review, reliance or distribution by others or forwarding without express permission /\ is strictly prohibited. If you are /\ | \ not the intended recipient please | \ / | contact the sender and delete / \ \ all copies. /\_/ K2 \_ \_ ______________________________/\/ \ \ John Stickley \ \ \ Mgr., Acceleration Methodologies \ \________________ Mentor Graphics - MED \_ 17 E. Cedar Place \ john_stickley@mentor.com Ramsey, NJ 07446 \ Phone: (201) 818-2585 ________________________________________________________________ -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean.Received on Thu Apr 19 09:25:14 2007
This archive was generated by hypermail 2.1.8 : Thu Apr 19 2007 - 09:25:17 PDT