Essentially dead - and not proper.

The input-"xor" macro-gate of copycat82, is essentially dead.

copycat82 admits that when two places get enabled simultaneously, it is a deadlock unless other components modify it (p.46) - but it never shows that "unless" in any example to resolve any deadlock. In ex-state, simply to add more tokens, will not do.

The input-"xor" corresponds to the Y-transition of E-nets, with no resolution. Although an E-net Y-transition, may also start a turn with no-resolution, that resolution is inherent to arrive right next - through the dynamic E-net-architecture, with the resolution procedures.

begging the question

copycat82 uses input-"xor" in some wishful manner, to express "mutual exclusion." That obviously assumes being able to identify "deadlock-corners" ahead of time - whereas Petri nets identify deadlock with lack of tokens (i.e: not terminate properly).

copycat82 only crosses two inhibitor arcs, to stop each other. This is the most-primitive way, you could use an inhibitor arc. Although it is quite easy to use inhibitor arcs to express ideas, to use the input-"xor" may feel quite blunted. It limits the applicability of inhibitor-arcs to only explicitly-known deadlock corners - a bit similar to "assert" in C, which stops the execution. But here, the side-effects may go unnoticed.

unproper, when dead

A subnet with an "input-xor" anywhere in it, is, potentially, not proper, i.e: when/if a deadlock occurs, it changes the subnet-response.

If two tokens may ever arrive simultaneously, "xor" is unproper.

If two tokens may never arrive simultaneously, "xor" is only equivalent to a place/location with two inbound arcs (and also, to the other dataless copies of Y-transition, the "another-inclusive-or" and "priority").

Therefore, in a verified and reduced subnet, input-"xor" is never needed.

buried gotcha

That is contagious, too. Even when an example, by itself, may not deadlock, in its two or three levels of nestedness, it may still crush, when in a circuit (e.g: in a loop).

If a deadlock-potential still lurks within that subnet, that means the attempt to reduce it, is only catastrophical. Although most, if not all, examples of copycat82 with input-"xor" may be deadlocked in some container-net circuit configuration, copycat82 still insists to claim to verify the subnets separately (instead of any necessary macro-expansion phase). It is russian-roulette, to trust such a subnet (as if equivalent), at all.

SARA CFA verifies the full-net together (except any valid reductions), but copycat82 assumes separate-verifiability. e.g: How was that "monitor" example of copycat82 (p.72) verified, if at all?

copycat82 examples: caught in its own traps

Most of the examples of copycat82, do get deadlocked - because both places may really get enabled, together. If copycat82 were ever to attempt to verify those sloppy examples, they would not probably be published with such obvious problems.

Why publish a deadlock macro?

copycat82 uses a pair of mutual inhibitor-arcs, to invoke a deadlock (which also commits to Turing equivalence). Why need that macro? If ever a need were to occur, a net-modeler could trivially cross two inhibitor-arcs to invoke such a deadlock. This is easier to remember than the name input-"xor" - which only means, in fact, a deadlock.

Although copycat82 commits a lot of bad (deadlockful) examples, it never provides an example of a facility to resolve any deadlock, and/or to suggest why such an abusable macro-gate was ever needed/wanted - all of those examples being awful examples.

Further Reading

The plagiarism of copycat82 encompasses its input-gate, and its output-gate, too.

Forum: . . (Fair Menu . . . . . Fault Report? . . . . . Remedy for your case . . . . . Noticed Plagiarism?)

Referring#: 0
Last-Revised (text) on Nov. 21, 2004 . . . that was
mirror to, on June 17, 2009
Written by: Ahmed Ferzan/Ferzen R Midyat-Zila (or, Earth)
Copyright (c) 2004, 2009 Ferzan Midyat. All rights reserved.