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

Hi Per,

>-----Original Message-----
>
>Of course, this is a just a matter of definition of the term `yield',
>but to be consistent with how we've been using it on the software
>side that is how it should be defined.  We can use `synchronization'
>for the other kind of yield when the HDL side needs to communicate
>with the software side.
[Shabtay] I like this suggestion as it will distinguish between the two
term and avoid confusion.
>
>> [Shabtay] Actually here you hit on a question I wanted to ask.
>> When the producer was notified by the ok_to_send() callback, what if
it
>> doesn't send any new elements for whatever reason. Maybe once
notified
>> it wants to wait on a different callback.
>>
>> If this scenario is mot implemented correctly, it may lead to a
>> deadlock. However I assume that in SCE-MI 2.0, responding to
>> ok_to_send() w/o sending any elements is allowed.
>
>Yes, I would agree that that is allowed.  It would be very hard if not
>impossible to check if the ok_to_send() callback resulted directly or
>indirectly in elements being sent.   And yes, it is possible to create
>a deadlock with this interface as it was with SCE-MI 1.x and UNIX
pipes,
>sockets, etc.
[Shabtay] Ok. I didn't intend to criticize the fact that it can
deadlock. I just wanted to clarify what is being proposed.

>
>> So obviously input pipe empty detected by a blocking receive call
will
>> cause a yield from the consumer to the producer. However if the
consumer
>> chose to use the try_receive call which failed, the actual detection
of
>> the buffer being empty does NOT cause the consumer to yield to the
>> producer side of the pipe (or the to another thread).
>
>Here you're talking about synchronizations which is different from
>the consumer yielding to another `thread' on its side of the interface.
[Shabtay] Correct.

>I am not sure we need to specify when synchronizations happen.
Shouldn't
>that be up to the implementation?  The implementor should be free to
>decide when the hardware and software side communicate.  We need to
>specify the behavior such that applications produce the same results
>on different implementations, but not the details of how this is
>achieved.
>
>> [Shabtay]Yes. I want to make sure that in the current proposal, the
>> implementation does not yield to the producer when input pipe become
>> empty while called by try_receive.
>
>I'm wondering why you think this needs to be specified?  Or perhaps
>you're asking if what you describe is a legal implementation of the
>specification?  This is of course a weaker statement but definitely
>worth clarifying.  I agree that an implementation is not required
>to synchronize in the scenario you describe.  I am not sure if the
>spec requires it not to.
[Shabtay] When either blocking or non-blocking calls are called by the
consumer, the implementation is "in control" at this time and it could
for example "unblock" the producer side blocking send given that the
#elements in the pipes have been consumed by the consumer. 

On the other hand, it could let the user determine (implicitly) when
(HDL/C) synchronization occurs such that these happen only if and when
the consumer thread yields to other threads in the environment. 

Users will see the difference between such two implementations.

For example if non blocking try_receive is being used exclusively to
move elements on an input pipe, an implementation can all ok_to_send
before try_receive returns with a FAIL message to allow the producer add
more elements. Alternatively, it could simply return fail flag and let
the consumer yield its thread explicitly resulting in a synchronization
that will allow the consumer to send more elemnts.

Do you agree that there is a difference?

John,

I understand that your proposal does NOT allow (HDL/C) synchronizations
to be initiated by the implementation during a non blocking call, but
rather to happen implicitly at the control of the end user code
(blocking call, flush, etc.). 

Please confirm.






>
>Per
>
>


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