Responses to IMs 3, 6, 8, 9, 10

Per,

Here are some responses to IMs that I've discussed with Duaine and
others here at Mentor.

=================================================================
IM03 - Prefixes

Bojsen, Per wrote:
> > What does the committee think about the following alternative
> > wording for IM03 based on the above:
>
> Sorry, I forgot the Sce_Mi prefix. Here is the corrected
> alternative wording:
>
> Prefixes beginning with the five-letter sequence s, c, e,
> m, i, or the six-letter sequence s, c, e, _ (underscore),
> m, i, in any case combination, are reserved for use by SCE-MI
> and SCE-MI related specifications.
>
> Enjoy,
> Per
>

We agree with this and find it acceptable for addition to the spec.

=================================================================
IM06 - ServiceLoop issues

Bojsen, Per wrote:
> Hi John,
>
> > Here is the suggested rewording of section 5.3.3.6 on the g() function
> > as per my action item for IM06:
>
> This is a big improvement over the original text! I have only a
> couple of comments:
>
> > For purposes of discussions of the g() function in this section,
> > "output message" is considered to be one of the following:
> > o An arriving message in a SCE-MI message output port that will
> > result in a receive callback being called.
> > o An input ready notification that will result in an input ready
> > callback being called.
>
> While this text is really clear to me, I worry that overloading
> the term `output message' is going to cause confusion, especially
> when people go back some time later and only read the g()
> examples. Perhaps we should define a special term for this, such
> as `service request'. We can define service request using your
> words:
>
> A service request is defined to be one of the following:
>
> o An arriving message in a SCE-MI message output port that will result
> in a receive callback being called.
> o An input ready notification that will result in an input ready
> callback being called.
>
> Then replace `output message' with `service request' in your
> proposed text.
>
> What do you think?

johnS:
It seems reasonable to replace 'output message' with the more
general term 'service request' as you've suggested while leaving
the remainder of the re-wording I proposed the same.

Bojsen, Per wrote:
> Finally, there is still an unresolved question I have with regards
> to the pending flag passed to the g() function. Imagine an
> implementation that must poll the hardware side to find out if
> a port has a message for it. The ServiceLoop() would poll
> output ports until it finds a port with a message. It would
> then transfer the message and call the Receive() callback on
> the message. The question is, is g() supposed to be called
> before Receive() or after? If it is called after, pending in
> this implementation would always be false since by definition
> the ServiceLoop() is unaware of any messages on the hardware
> side untill it polls the ports and it always processes messages
> it becomes aware of immediately. If g() is called before
> the Receive() (or IsReady()) callback then pending will always
> be true. Hmm, this leads me to conclude that g() should be
> called for each `service request' *after* it has been handled
> by its callback and the pending flag is supposed to indicate
> if there are any more `service requests' that the ServiceLoop()
> is aware of pending to be handled. In my example implementation
> pending will always be false, then.

johnS:

We're in agreement on one issue but not the other.
We agree that g() should be called after servicing the
request.

But we slightly disagree on the meaning of the pending flag.
The original idea is that the pending flag reflects the
status of the message queues at the time ::ServiceLoop() was
called. So, if there was 1 message at the time ::ServiceLoop()
was called, the message is serviced, then g() is called.

Pending is set to 1 in this case because there was at least
one message when ::ServiceLoop() was called. Doing it this way
makes it easier for the application to unabiguously control
the behavior of ::SerivceLoop() i.e. make it blocking, polling,
wait for 1 message, etc.

>
> Now, take a look at example 5.3.3.6.3. In this example, if
> pending is always false, haveProcessedAtLeast1Message can
> never become 1 and g() will always return 1, i.e., the
> ServiceLoop() will never exit. Yet the ServiceLoop() can
> process any number of `service requests'. Given that the
> example is supposed to show how to make ServiceLoop() block
> until at *least* 1 message has been processed implying it
> may block until more than 1 message has been processed, I
> think the example is still valid, although a user might
> be surprised at how it works with an implementation like
> the one I've described.
>
> Do you agree that an implementation may behave as I described
> it (never being aware of more than 1 message)?

johnS:
Assuming that 'pending' reflects the message status upon entry
to ::ServiceLoop() as I described above, I don't agree. I think
the example should work correctly.

=================================================================
IM08 - Message Output Port Prorities - Hints or Required ?

johnS:
I propose that we take out the "hint" language and just
make it required.

This removes ambiguity from the spec.

Here is proposed new wording for section "5.2.1 Parameters",
paragraph under "Message output port priority":

<beginning-of-rewording>
"The priority of a message output port shall be derived from the
PortPrority parameter defined in the SceMiMessageOutPort macro.
This must be used by the infrastructure linker to decide which
output ports to service first (when they present message data
on the same uclock) and are implemented over a number of “physical
message channels” which is less than the limitless number of virtual
message channels. For those who do not care, the default value of
10 does not need to be overridden and need not be specified in the
instantiation statement.

"With some the output port priority must follow the following semantics:
— 0 < allowed priority values < 20
— The default priority value is 10.
— The lower the number, the higher the priority.
— Output port priority 0 is reserved for internal use by the infrastructure.
— For message output ports with the same priority number, their relative
   priority is undetermined and strictly an artifact of infrastructure
   linker implementation."

<end-of-rewording>

=================================================================
IM09 - Port Priorities

johnS:
I propose remove references to the Unix "nice" command and just state
the semantics explicitly.

I've done this in the reworded text shown above for IM08.

=================================================================
IM10 - Demo Problem

johnS:
We agree with Per's proposed changes here.

-- johnS

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 \ \ \
Principal Engineer \ \________________
Mentor Graphics - MED \_
17 E. Cedar Place \ john_stickley@mentor.com
Ramsey, NJ 07446 \ Phone: (201) 818-2585
________________________________________________________________
Received on Wed Mar 24 15:41:28 2004