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

Hi John,

 

I have pulled the sections you changed into this email. Please confirm
that these are indeed all sections changed. I'd like to suggest that we
first resolve all proposed changes by email before Brian moves the
changes into the new draft.

 

First section:

 

The (*scemi_pipe_c_notify_ok_to_send)() and
(*scemi_pipe_c_notify_ok_to_receive)() functions are programmable
callbacks that are denoted here as function pointers rather than actual
functions. They are called from within the infrastructure to notify the
C-side application that the number of elements in the pipe has changed
as a result of a recent send or receive operation.

For example, if a C-side consumer attempts to receive some number of
elements from a pipe that are not all available, it may wish to go to
sleep but be notified when one or more elements are sent by the producer
at the other end. In this case the infrastructure would notify the
consumer via the OK to receive callback.

Conversely, if a C-side producer attempts to send some number of
elements to a pipe that does not have enough room for all of them, it
may wish to go to sleep but be notified when one or more elements are
received by the consumer at the other end. In this case the
infrastructure would notify the producer via the OK to send callback.

See section 5.7.4.1.3 for specific semantics governing when the
infrastructure would call the notify functions.

These functions typically get registered by the C-side application at
initialization time although they can be registered at any time.
Additionally, previously registered notify function pointer can, at any
time, be replaced with another.

Second section:

 

The infrastructure shall call the notify callbacks specifically under
the following circumstances:

A send() or try_send() operation has been performed on an output pipe
that adds to the number of elements previously in it. In this case, the
OK to receive callback on the C-side will be called exactly once in any
interval of execution during which the infrastructure has control of the
thread in which the pipe is being updated - regardless of how many
elements were added during interval of control.

[Shabtay] "in any interval of execution during which the infrastructure
has control of the thread in which the pipe is being updated" is not
clear to me. Isn't "each time the infrastructure is called it has
control of the thread" implementation specific? One possible way to look
at this is that each time the infrastructure is called it can control of
the thread. Another way is that each time infrastructure is called and
the call is not satisfied, the infrastructure has control of the thread.


 

Which of the above interpretations you intended to convey (unless there
is a third one)? 

 

A receive() or try_receive() operation has been performed on an input
pipe that reduces the number of elements previously in it. In this case,
the OK to send callback on the C-side will be called exactly once in any
interval of execution during which the infrastructure has control of the
thread in in which the pipe is being updated - regardless of how many
elements were removed during that interval of control.

 

 

For example suppose a blocking receive() operation needs to perform the
equivalent of 2 try_receive() operations in order to remove all the
requested elements from an input pipe, since the first try_receive()
could only partially fill the request. Between the two operations it
would, by definition, need to suspend its thread (to yield to the other
end of the pipe to send more elements). Assuming each of the 2
try_receive() operations altered the number of elements in the pipe,
this would result in exactly 2 notify OK to send callbacks to the C side
- one during each try_receive() operation.

[Shabtay]From your example, I deduct that both blocking calls and non
blocking calls can suspend the HW side (aka block) and call the OK to
send callback. Your example shows that try_receive() actually caused the
producer to add more elements to the pipe. If callbacks are allowed in
this case, I assume these take place if try_receive() does not have
enough elements in the buffer by your proposal and thus try_receive()
will never fail.

 

Is this correct?

 

 

 

>-----Original Message-----

>From: owner-itc@eda.org [mailto:owner-itc@eda.org] On Behalf Of John

>Stickley

>Sent: Thursday, April 12, 2007 12:28 PM

>To: 'itc@eda.org'

>Subject: my action item for explaining semantics of notify callbacks in

>SCE-MI pipes

> 

>Greetings ITC Techies,

> 

>As per my AI, I've created a modified version of the spec

>that explains the specific semantics of notify callback

>in SCE-MI pipes.

> 

>I've reset change bars from the MainBody_v3_070125-johnS-3.doc

>so that only these updates are highlighted.

> 

>That way, if it looks acceptable, it should be easy for Brian to

>merge into the new draft.

> 

>Per reflector limitations, I'll send it as a separate attachment called

> 

>     MainBody_v3_070125-johnS-4.doc

> 

>in another e-mail.

> 

>-- johnS

> 

>______________________________/\/            \     \

>John Stickley                   \             \     \

>Mgr., Acceleration Methodologies \             \________________

>Mentor Graphics - MED             \_

>________________________________________________________________

> 

> 

>--

>This message has been scanned for viruses and

>dangerous content by MailScanner, and is

>believed to be clean.

 


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