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

Per, John,

>-----Original Message-----
>From: Per Bojsen [mailto:per.bojsen@amd.com]
>Sent: Friday, April 20, 2007 11:18 AM
>To: Shabtay Matalon
>Cc: John Stickley; itc@eda.org
>Subject: Re: my action item for explaining semantics of notify
callbacks in
>SCE-MI pipes
>
>Hi Shabtay,
>
>> So obviously input pipe empty detected by a blocking receive call
will
>> cause a yield. However if the user chose the try_receive call which
>> failed, the actual detection of the buffer being empty does NOT cause
a
>> yield.
>
>Perhaps the confusion stems from using the term `yield' without
>qualifying whether it is the consumer or producer that is yielding.
[Shabtay] BTW, I was analyzing from the consumer side.

>If the consumer is calling try_receive() and it indicates no elements
>were transferred because the pipe is empty, an ok_to_send() callback
>will *not* be invoked because the state of the pipe did not change.
[Shabtay] Understood. 

>However, if the consumer will now have to wait a while before trying
>again, e.g., it will have to yield to another thread and/or the
>producer side of the pipe.  
[Shabtay] Correct.

BTW, if I am looking at a consumer from the HDL side, the term "yield to
another (HDL) thread" sounds awkward to me.  The HDL side is concurrent
in nature. "Yield" (which I also call synchronization) will happen using
blocking calls on any of pipes, or flush on output pipe anywhere in the
HDL side. 


The reason a callback is not needed is
>because the try_send() on the producer side will allow at least 1
>element to be transferred.   This is guaranteed because we assumed
>the pipe is empty.
[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. 

John, Can you confirm that?


>
>I think the above is what John stated.  I am not sure where the
confusion
>is or what point you are trying to make?  
[Shabtay] Let me correct my statement:

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).


>Is there some hole you're
>trying to uncover or make sure doesn't exist?
[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. 

>
>Per
>


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