Shabtay’s take 04/28 - High level clarification exchange. Issue resolved and no action needed.

Committee agrees

SCE-MI 2.0 Pipes - need to flesh out the recommended (required?) use-model and test architecture in which pipes work

a) Is pipe depth left up to vendors, or is this user-controlled?

b) What is a full pipe?

c) Threading requirements, flush mechanism, blocking semantics of pipes, control flow in general

d) Development of a full example/tutorial

** See consolidated proposal from JohnS in IM208 dealing with IM's 208-211

Pipes can be layered over an alternating mechanism to obtain data on a continuous basis. Flushing is a synchronization point at which reactive things can happen. Mentor to provide a proposal for this.

Shabtay > I was under the impression that pipes are intended to be used for streaming channels. Is this the not the case? Can someone clarify if pipes are used for any type of channel (streaming or reactive) of just streaming and on which basis the user will choose using pipes vs. using DPI directly?

Per> It is my understanding that pipes are intended for streaming, batching, variable length messages, and potentially can be used even for more exotic purposes if the modeling subset allows it. Given that pipes can be implemented at the application layer, the choice between using pipes and DPI is one of convenience in many cases. However, since an implementation can choose to provide an optimized version of the pipes, this would be a factor as well in the choice to use them.

Shabtay> We had some discussion about setting buffer depth for pipes. It was my understanding that Mentor proposes setting the buffer depth by the infrastructure and not by the user. Is this correct?

Per > This is my understanding as well. If the system is deterministic and observes alternating semantics, then I do not see any need for a user setting of buffer depth. This is because the buffer depth setting would have no observable impact on the behavior of the system. There are other problems with a user settable buffer depth: it is unlikely that a given buffer depth setting would achieve optimum performance in all implementations. Note, I am saying that I do not think a user setting for buffer depth should be in the SCE-MI 2.0 standard. However, any implementation is free to provide its own performance optimization knobs outside of the standard which could include buffer depth setting. I do not see such features as leading to a non-compliant implementation(necessarily).

Shabtay>> User should not care about any buffering that it set by the implementation as long as message arrival ordering on various channels is not impacted by the setting of implementation buffer depth.

Per> Pipes are set to enable delayed arrival. Correct? Who sets this delay? The transactor model or the end user (who may be the recipient of a block box transactor)? Have we touched on this question yet?

johnS >

I think the main point here is that it does not matter who sets the delay or what the delay is so long as there is a mechanism to re-synchronize the times of the pipe producer and pipe consumer if it becomes necessary to enter back into a mode of reactive (alternating) interactions. This is the purpose of the flush call - to provide this re-synchronization.

For example, a pipe producer thread can be sitting there jamming transactions into a pipe to its heart's content. The consumer meanwhile is only consuming transactions which the producer had written well into the past.

So in this scenario at any given point the consumer's time, the producer is well into the future - how far into it, we don't care.

Or, put differently, at any given point in the producer's time, the consumer is well into the past. How far into it, we don't care.

But suppose producer and consumer now want to interact reactively, say with plain DPI function call interactions. They must synchronize. i.e. the producer's present must become one and the same as the consumer's present. To do this, producer issues a flush. This guarantees that the producer thread blocks until all the future transactions have dissipated to the consumer and now the two are synchronized in time. At this point in time, the two have a common present and are free to communicate reactively. And all this can be done deterministically where interactions take place on the same clocks on timed side regardless of how much buffering an implementation provided or how much concurrency it chose to use.

<<End JohnS

Shabtay> How would user obtain matching results if each implementation sets its own buffer depth?

Per> By the simple fact that the pipes are deterministic.