Interface Automata

1. Interface Automata Dr. Winthrop T. Williams EE 290n, Concurrent models of computation U. C. Berkeley May 15, 2002

2. This talk is organized into 3 parts. • The PN – SDF mystery. • Including DE & CSP in this new partial order. • Extensions to Interface Automata semantics.

3. The PN – SDF mystery: • Steve Neuendorffer has pointed out that models which run in SDF, also run in PN. • By contrast, the partial order of Ptolemy domains (as presented at EMSOFT 2001*) showed PN being incomparable with SDF. • What’s going on? I have factored each domain into a Director automaton and Receiver automaton. I will compare these for PN and SDF separately and in combination with typical SDF actors. http://ptolemy.eecs.berkeley.edu/publications/papers/01/systemLevelType/ System-Level Types for Component-Based Design. Edward A. Lee and Yuhong Xiong. LNCS 2211, p. 237 ff. *

4. SDF Director

5. SDF Receiver

6. PN Director

7. PN Receiver

8. How do PN and SDF compare? Compare the Receivers: Open the PN Receiver in Vergil. Compose with the complement of the SDF Receiver.

13. That worked! This shows that PN’s receiver can handle • Anything which SDF’s Receiver can. • Now, compare the Directors: • Open the PN Director in Vergil (ex. for the reader). • Compose with the complement of the SDF Director. • This does not work. (I’d need both to work for proof by • this approach.) • So, new approach: Add an SDF Producer actor to the PN Director & Receiver. Eventually add an SDF Consumer actor too, and see now they compose.

14. PN Director SDF Producer PN Receiver

15. These three automata compose to a 32 state automaton with two input and two output ports. In the following diagram I’ve arranged the layout by grouping together states which have the same third number. The third number is the PN Receiver state number. The diagram after that is a whittled down version. The internal transitions for the firing of the producer (fProducer; and fProducerR;) have been removed.

16. PNDirector_SDFProducer_PNReceiver2.xml

17. PNDirector_SDFProducer_PNReceiverWhittled.xml

18. Now, let’s compose this with a typical SDF Consumer. SDFConsumer.xml

20. So, we see how SDF actors do, in fact, work in PN. What about the other domains? • I will focus on how a consumer actor works in various domains. A similar analysis can be done for producers. In fact, many actors have both consumer facets and producer facets. I will come to an actor with two consumer facets when I discuss CSP. • Notice that, up to now, I have not included the hasToken() interactions. This is because, for PN and SDF, it has not been pertinent. SDF fires the consumer only after data is available. PN always claims there is a token available, and then makes this true by having the consumer block in get() until there really is one. • As I include hasToken() in the discussion, I remove the firing of the producer and the putting of tokens by the producer into the receiver. SDF fires the producer only when the consumer is not firing, while PN fires the producer primarily when the consumer is firing. This difference confuses compatibility issues, so I’ll leave the producer’s firing and token putting out of the following diagrams.

21. PN Consumer (maximal actor)

22. SDF Consumer (maximal actor)

23. DE Consumer (maximal actor)

24. … also work in these domains. PN Composing these with each other’s complements, we see that a DE actor is compatible anywhere an SDF actor is (since the DE actor is compatible with SDF’s complement). Likewise, these diagrams confirm that an SDF actor is compatible anywhere a PN actor is SDF DE Actors which work In these domains …

25. What about CSP? CSP is much like PN, but with zero length queues in its receivers. The key feature of CSP is poly-blocking, the ability to simultaneously await data on more than one input. CSP even allows an actor to simultaneously await data arrival and room for data dispersal. The next slide compares CSP and PN consumer actors. The left column shows one-facet consumers. PN and CSP are identical with only one facet (a.k.a. port). The right column compares CSP and PN when each has two input facets. Notice that the 2 input CSP actor’s automaton has a new output transition labeled “gg2”. This is the poly-get request that simultaneously requests a token from each receiver, with the caveat that it will take only whichever token comes first. What, then, must be the automaton of the CSP receiver? First, I’ll diagram the two receivers as a pair, then I will factor them apart.

26. PN: CSP: Single input Consumer: (Identical in PN & CSP) 2 input Consumer: (CSP actor has added freedom)

27. CSP Dual Receiver automaton for two CSP receivers (of a 2 Input Consumer actor) as a pair. For simplicity, I have diagramed only the poly-blocking case. CSP actors may also single-block.

29. This factoring can be checked by composing to re-form the dual receiver. Because the Ptolemy composition tool in Vergil does not recognize fan-out, I use the following workarounds: • Rename “gg2” to something else in one of the factors. I do this because it is an input common to both factors and would otherwise conflict. • For the “pR” and “p2R” inputs, add self-loop transitions where ever there isn’t an actual transition. Otherwise, legitimate output transitions are missed in the composition. • Compose with the other factor. (This step isn’t a workaround!) • Finally, rename the alternate gg2 name back to “gg2” and then eliminate traces where a 2nd “gg2” occurs before the first is satisfied with a “t” or “t2”. Remove states which become unreachable. The next slide shows the result. This matches the diagram I was attempting to factor.

31. Here’s the partial order resulting from the forgoing analysis: NaT … also work in these domains. CSP PN SDF DE Actors which work In these domains … DP

32. The 3rd and final part of this talk is about extensions to the semantics (and syntax) of Interface Automata. We have already seen fan-out. There is alsofan-in. I have used arrows of a different width and color to distinguish these from state transitions. I have also enclosed each automaton to clarify which ports belong to it. Alternatively, the port icons may be eliminated and the thick colored arrow may be drawn directly to one of the transitions. If the diagram has only one transition corresponding to this input or output, then no label is required. I have worked out semantics for fan-out and for fan-in. An especially interesting case of fanning is conditional fan-out. This is shown as a transition with both an input label and an output label. I have worked out semantics for these as well.

33. 0 x? y! 2 x? z! 1 Conditional fan-out. Conditional fan-out is particularly useful when describing the interaction of several threads synchronizing, waiting, and notifying on a shared resource. Without conditional fan-out, many threaded systems cannot be adequately factored.

34. Open Questions & Issues • Pre/post fire is not addressed. The fireAt*() methods are not addressed in DE’s automaton. • FSM isn’t in my partial order. Could add it by seeing it as State Actors linked by Transition Actors. • Value of showing full complexity. Director Description Language using Automata may be possible. • Single-input DE actors oughtn’t be required to call hasToken() unless it calls fireAt*(), yet my diagram for DE requires it to do so. • I modeled PN as only permitting token passing when fired, but the Receiver and Director automata would have permitted token passing and hasToken() calls anytime. • Needing to add a producer actor in order to test domain ordering is unsettling. I don’t know how else to model that the producer & consumer cannot actually gang up on the Director & Receiver. • Vergil’s composition tool is mainly useful for testing/checking. Diagrams are faster hand drawn. • Difficulty of teasing state diagram into readability was glossed over. Lay out by state value (Eylon). • Composing CSPReceiver with SDFReceiver Complement yields a 2-state acyclic diagram. This raises the question of how much composition result is enough for “compatibility”? • Manifold states (another extension to semantics) were not covered. • Conditional Send in Yuhong’s 2-philosopher example is worth study by me. • My own 53 state factoring of the 2-philosopher problem wasn’t presented. • Giving the CSPDualReceiver full freedom of return order (t[2] vs p[2]R) complicates factoring. One solution is to have a single output transition fan out to both “t” and “pR”. • The difficulty of factoring w/o [conditional]fan-out wasn’t presented. E.g. trying to factor out “1”. • Thread Interaction diagrams made before I redirected this talk to Ptolemy Domains weren’t presented.

35. References (for the author to learn more!) • Dill(?) has written of composing automata with complements of other automata. • StateCharts has similar structures to my extensions of Interface Automata. (From Jim Anderson) • Much thanks to Yuhong, Tom, Luca, Xiaojun, Christoph, John Davis, and Edward Lee for their work and interaction leading to my insights.