((There is only the Fig 3.7, on the page 68. It has five parts. The corresponding figure in the copycat83, is the fig.6 (p.741) - except the fifth part (3.7.e of copycat82 versus the fig.6.e of the copycat83).))

Fig 3.7 The origin of the input/output-transfer macros.

The caption reads "The graphical representation of some common operations." As a matter of fact, the first four parts correspond to the E-nets primitives, Y-transition, J-transition, F-transition, and X-transition, respectively. And they are visual evidence, for the E-net-likeness of the copycat82's graphical aspirations.

The fig.1 of NoeNut73 (p.719) lists the five primitive transitions of E-Nets, before going on the discussion with the Macro E-Nets. We compare that figure with the corresponding figure in the copycat82. The similarities are hinting/pointing to the origin of the idea of representing the input/output macros.

Fig.3.7.a E-nets Y-transition, with constant priority

This is the Y-transition of E-nets redrawn, by making its capabilities explicit. The priority is constant, as the copycat82 cannot switch the priorities, at simulation time. For this example, that may be passable. But even that assumes, the instruction is part of a low-priority task. If some higher-priority, uninterruptible task, would call the same routine, then the priorities had to be reversed. The copycat82's static'izing of the E-net primitives has such limitations, without bringing any adavantages.

The caption of the example reads "An operation with interrupt and exception conditions." But the truth is that, unless at the undivisible machine code level of a CPU (or with a bus-lock mechanism, while the intruction is executing), this would not work at any level. And then, to model individual instructions, such an explicit presentation is gross. Imagine repeating the same sort of luggage, for each and every instruction, in a graph, when representing at the machine-code level.

The interpretation, without reading the captions, and/or without wishful thinking, is further bizarre. We have only a figure, and a caption. No further any formal anything. Let's interpret it with its vagueness, then:

• The priority is applicable only at the very start of the operation, and unlike E-nets, there is no way to stop the other one from entering right after the first one. This is the very nature, of the implemented "priority-++-in" macro. Where do we see a lock? If no locks, where do we see what prohibits that interrupt from entering after that instruction, once the "start" has already started? And if some implicit bus-locks, where is the code that lets the interrupt wait the next operation, after this operation is finished? Otherwise, does that interrupt get ignored, any more? A "benefit-of-doubt" may suggest that it may do what E-nets do, in the case of tokens. But then, how is that different than E-nets, if claiming to be something new, at all? The priorities, and some other features of E-nets have been made constant-only, static versions, and if the no-examples-given part (the operation of the token-flow modification, procedurally) is exactly like E-nets, how is that not plagiarism? If it is something different, then where is it? Nowhere in the copycat82.

As a point of notice, that "data-type" rectangle, with a "T" in it, is the all and only showing of such a rectangle in the whole copycat82 - except in the sample figures that advertise "how to draw the rectangles and arcs," and "how to show a box with a "T" in it as two boxes, with "T1" and "T2" in them" and even that is faulty/inaccurate, believe it or not. (See about pages 105-116). This showing of that "data-type" rectangle, again, as in the case of data-item rectangles in the graphs, has no use.

Fig.3.7.b E-nets J(oin)-transition sitting as "and-in"

This is the Join-transition (J-transition) of E-nets, and the usual Petri nets transition, with two preceding places. The E-nets describe themselves as a Petri net extension. The copycat82 also claims that, although most, if not all, of its extensions are E-net'ish. This, J-transition, may be a minor point, but the rest is also that way.

The caption reads "a "join" operation", and the figure is a rectangle with the word "synch" in it. There are two preceding and one following places, and there is an asterisk between the preceding arcs. This is the way SARA (UCLA graphs), shows its input/output logic.

The preference of the name "and" over "join" as the name of the transition, is a bad choice, as it interferes with the Pascal-language "and" operation, in those program-fragment rectangles. That is, choosing the SARA-naming is not an improvement, when presenting software. I discuss this further, elsewhere, among these pages. And it is not "enough difference" from E-nets, to switch to other names, for the same operations, or providing static-versions.

Fig.3.7.c E-nets F(ork)-transition sitting as "and-out"

The same discussion applies, as in the case of J-transition. There is an asterisk between the following/outgoing arcs. The text in the rectangle reads "Parallel Start", and the figure caption reads "a "fork" operation."

Fig.3.7.d E-nets X-transition sitting as "xor-out"

The same discussion applies. And this further points out the similarity with E-nets. There is a small rectangle with the name of a data-item in it, the same way there would be a resolution location, with an X-transition (the output switch) of E-nets. The caption reads "a conditional branch," the rectangle reads "Branch on C," and that small data-item rectangle reads "C."

The E-nets resemblance is so much that, the figure (d) even sports a data box pointing to it, exactly corresponding to the resolution place in the X-transition. (Not to mention that, unlike for the X-transition, that "input-data" is never taken care of when the Petri net part is being verified. It stays there only to be pruned away, at the Petri net verification phase. Vestigial.)

In the source paper, N&N-73, the reason for taking data-dependencies into account is explained as:

Petri nets show structure and resources along with some control and data flow paths, although they do not show actual flow of data since only simple tokens are passed from point to point inPetri nets. They do show parallelism, but do not provide for conflict resolution, which is indeterminate with respect to the process being modeled.
(Noe and Nutt (1973, p.719), emphasis added)

V&D also calls for employing data for checking determinism and determinacy. (See p.182,p.191)

Never, in any example, those "data-item" rectangles are not good for anything, in the copycat82, maybe except as a form of commentary, but not even that, because every shared variable must/may be accompanied with a sharing-co-ordinating Petri net place. Do not confuse these with the interactive debug-variables of a debugger, and everything is on the paper, any way. They only make the graph more crowded. And for value-tracing, we would want being able to switch them on/off, and those arcs traveling around the graphs, and getting torn apart, at the other levels, are nothing relevant. Therefore, this is not that. Period. The E-nets resolution locations have their values changing over the course of a simulation, and NoeNut73, for example, present a trace of an example simulation. The copycat82, although a full text of a dissertation, lacks any (approvable) suggestion for the utility of those data-items.

Danthine (1980) combines the X-transition of E-nets with time Petri nets, as part of its paper.

Fig.3.7.e Elongating a [non-counting] "semaphore P(s)"

The fifth part is a senseless implementtation of a semaphore, apparently which, the implementor oneself did not understand at what context, that could be used/meaningful, if at all.

If this is a counting-semaphore, and the "s" is the counter, where is the corresponding Petri net place? Without that, the Petri net analysis, when the data-rectangles will be discarded, as the copycat82 does, the analysis will give wrong results.

If this is a counting-semaphore, but the "s" is not the counting variable, then why bother elongate it to this size? A single mutex place could suffice, as Peterson (1977) shows in a simple example, and the operation on "s" would not be a decrement (subtract one), but an assignment of zero. That is, all and only the place "savail" would suffice, for that.

Where is the corresponding semaphore V(s) operation? With only one half of a two, very interdependent subnets, this is not a full example, at any size, in fact. Only a sample figure of something.

Further Reading

(page-by-page raw-dumps section) . . . . . previous . . . . . next