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

Per,

Comments ...


Per Bojsen wrote:
> Hi Shabtay,
> 
>> Actually, even if the first call at simulation start is a blocking
>> receive() on an empty pipe, by your proposal ok_to_send callback will
>> NOT be called.
> 
> 
> That should be OK as the producer on the C side would call the try_send()
> function and it would allow it to send as many elements as there is
> room for in the empty pipe.  There is no need for an ok_to_send callback
> at the beginning of time as far as I can see.

johnS:
Correct.

> 
> I've been thinking that we should be able to find an analogy to this
> protocol in the OS domain, specifically the BSD socket API or perhaps
> UNIX pipes.  Perhaps if we could refer to such well-proven designs
> we could increase our common understanding and level of comfort with
> the correctness of the protocol?
> 

johnS:
Actually the analogy I've been using is TLM's ok_to_put/get events
which I think are pretty well proven.

So there is some precedent for this. I have closely looked at
the TLM standard and am basing these semantics largely on it.

In fact, the whole original purpose of the thread-neutral callback
based notification system was so that it could be used as an
underlying mechanism to implement a thread aware TLM fifo.

There is a key difference however. Because TLM only supports single
element calls, we needed to expand the semantics somewhat
to allow for multi-element transactions in a single call (data shaping).
That's how I came up with the semantics currently proposed.

<eom>

> Per
> 
> 
> 
> 


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