Ready.
In Fig.6.6., copycat82 degenerates into giving the text of a whole chunk of the algorithm, for a semaphore-operation, in a single "subcomponent"-rectangle (i.e: (1) enter critical section with a P(sv), (2) do the critical task, (3) exit the critical section, with a V(sv) operation). How is that Petri nets?!? No integration of the semaphore into the Petri net logic. That whole subcomponent is started by a single place, and ends with a single place. In other words, there is no external specification for such a later-definition, either (i.e., among the components that use that semaphore variable).
In fact, the prior art (VD78, Da80, etc.) does discuss an incremental/preferential verifiability. But, using that for a semaphore-variable, sounds excessive. The shape of the net, will have to change in later, more expanded, steps, any way. As a result, the idea of "After defining external-specs for a component, its internal is definable." is irrelevant, at least, for this example. In other words, it is not "incremental design," (similar to VD78) as copycat82 (falsely) claims, but it is, in fact, transformational-rewritings, as Da80 suggests, I think. (See NN73, p.724 "alternatives in representation") The next time, if the semaphore is represented with a Petri net place, for mutual exclusion, as it is the very easy Petri net practice, that single-input subcomponent may acquire some new i/o place(s).
As such, a "semaphore-variable" is not represented in the Petri net graph, but it exists only as a(n internal) data-item. Next, please do keep in mind that, those data-items never get integrated into the Petri net verification process. As a result, talking of Petri nets, that mutual exclusion is totally ignored.
The later subcomponents are also such chunk listings.
There are two separate subcomponents within the component pcs. The only thing they "share" is an output place, oops, not really an output place, but a temporary-outgoing place, imitative of SARA socket-calls. The return places are, again, separate, though. This relates to the issue that
Assuming it were expanded as a macro, and meaningfully verified, would this possibly remove some of the deadlocks mentioned, in the previous pages? It is none of our business to guess it, of course. We are the readers. The dissertation-author(s) had to think about these, too, and had to do the studies, themselves. All we know is that the original algorithm, as published in CACM, must have been very likely true, and representing software, whether hierarchically, or as a single piece, was rather easy, with Petri nets (see Pe77, Fig.11, Fig.15). No need to introduce unmanaged degeneracies as discussed. In other words, while we would expect to find an improvement, in a Ph.D. dissertation, it turns out to lose, even the basic verifiability of Petri nets. In summary, no new algorithms, and no improvements in representation of it, either. What does copycat82 claim with this, at all?
As a point about another patch, let me also tell that, in this figure we find those data boxes being pointed-to, on an individual-variable basis (as opposed to being a list of 8 variables, in that "shared-memory" box, on page 148). But the thing is strange in another way. Those variables, in each case, are pointed-to by exactly one component at a time (except the msg11 which was not part of the original set. It is part of that "socket call"). In other words, when we finally find the place where the data is used, everything is "looking like" pointers (i.e., labels). This is so, even for rcs which gets used by two subcomponents within this figure, on this page, but each keeps its own rcs box, with the arrow pointing to it. As a result, could we please learn, where has even that thin make-up over the existing literature has gone to? This has become the same style of pointer/label-based correspondence, rather than the draw-all-together style. Only the shapes are different, then. Peterson (1977) points to flowchart-likeness of Petri nets, Valette and Diaz (1978) use labels for the correspondence of Petri net and data-flow graphs. And here, it is only another way of drawing shapes, which does not stick even with its own criteria.
That "single graph"ness, in fact, is about writing all the token-attributes of an E-nets token, with their names, parallel to the token. With that view, in fact, this figure also fits. But that is not what copycat82 itself says. From its own words, you would guess another (even if that is also trivial) sort of graph cut-and-paste: merging the control- and the data-graphs of VD78, at those points where a transition corresponds to a data-operator. The "look like both" has degenerated, as we notice in Fig.6.6.
In fact, there is a couple of variables (data-boxes), "n" adjacent to "me," as input to a subcomponent-box. In Fig.6.6., these are apart from any other subcomponent's data in/out, and they are drawn cheek-to-cheek (adjacent boxes), very suggestive of a token-attributes set of an E-nets node/transition, even visually.
In fact, that "exceptional" msg11 is weird in other ways although being used in two different ways, in one as a reply being sent, in the other, as a request message being sent, whereas the rcs is in both cases, only being read, it is the msg11 that represents the "common-data"ness. If even such a distinction had been made, the case should be the reverse, I think.
copycat82 is supposed to be a Ph.D. about "representation and analysis of ..." We keep pointing out its failures, its patchiness that could not pass as a methodology, etc.
As a result, you would not want to use it. Furthermore, it appears, even the author(s) cannot use it. The figures float in errors. Who verified/analyzed that, if at all? What sort of "Ph.D. study" is that, if its examples keep being only bad examples?
In two separate subcomponents, the loop-upper-limit "n" is shown as an input-variable in one of them, and ignored in the other. Which one is the correct?
In its abstract, copycat82 claims being insensitive-to-granularities of concurrency, and distributiont. But in a figure, when you reflect, the pointing to a data-box "rd" instead of the individual variable "rd[j]" at a time, is a representational choice, about granularity-of-access. In fact, this relates to the problem with the monolithic shared-memory in Fig.6.5., with its 8-variables-together. When all variables are lumped in a single data-box, any control-node (transition) that accesses any single data-item, blocks all the others. If it is a loop, why not release the already-modified? This could be. It would allow more concurrency. Thereby, it is a choice, in fact. As a result, copycat82 is wrong, I think, in its comments/claims about granularity - unless it means the usual (see Pe77, VD78) Petri net reduction/abstraction of subnets to an element, and neglecting the internal structure. But, when data enters the scene, those words are no more accurate, though.