Ready.
On this page, we will review/discuss the tutorial paper:
Pe77 is a literature-survey about Petri nets. It is an easy-to-read tutorial, with fine pointers. This page features several quotes from the Peterson paper. The copyright notice is:
A Petri net, has places and transitions, as its static elements.
The token flow, on a Petri net, is the dynamical aspect.
Petri net modeling best suits those systems, that have concurrency, and a need for mutual-exclusion, for ensuring correct operation. Peterson lists a few properties that make Petri nets useful in modeling (Pe77, pp.229-231):
Pe77 had written it:
Pe77 also has the figure 11 (p.231), demonstrating the capability. It is a very simple tool for modeling.
Pe77 has a subsection with the name "Modeling of Software" (pp.233-234). Fig.15 shows a program fragment translated into Petri nets. The critical-section in the program is enclosed with semaphore request/release operations (P(mutex), and V(mutex), respectively).
Peterson represents the program-fragment as a Petri net place. This tells us that the code is a process (a condition) that may take some unknown amount of time, which is the time the place holds a token (the observable condition, within the Petri net abstraction).
The place that corresponds to the critical section is enclosed between two transitions, corresponding to the P(mutex) and V(mutex). This fits very well to an understanding of the Petri net transitions as being instantaneous. That is, a transition takes no time, and as a result, no two transitions may overlap in time.
In Pe77, there is a subsection with the name "Modeling of Software" (pp.233-234). On p.234, there is the figure 15 that shows a program fragment translated into Petri net representation. The critical-section in the software is enclosed with semaphore request P(mutex), and the semaphore release V(mutex) operations. Peterson approach is to represent a program-fragment as a Petri net place enclosed between two transitions. This tells us that the code may take some unknown amount of time, which is the time the place holds a token. When the transition after the place fires, that means the execution-completion event has occurred. This is one side of it. And the other side is symmetrical. As a result, the figure is representing two figures which get into their own critical sections, when the other process is not in its critical section.
When the transition after the place fires, that means the execution-completion event has occurred. This is one side of it. The other side is symmetrical, and the two sides are mutually-excluded throough an intermediate place, which has a single token. A P(mutex) operation draws the token, and makes the other side wait until its place finishes its process, and deposits the token at the end, with a V(mutex) operation, that corresponds to the transition following the place. All in all, that Fig.15 is a very clean modeling of a system of two processes, each getting into their own critical sections, when the other process is not in its critical section.
Petri nets are verifiable with a reachability test. Pe77 refers to a point, as concerns the modeler. i.e: The locality, the modularity of the noticeable changes:
VD78 is an example of a methodology with modular Petri nets - with explicit restrictions for well-formed subnets.
Pe77 does not list what-to-do for preserving equivalence, for a reduced subnet to stand as a (non-primitive) transition, or as a place. We may do it, either with a list of restrictions, as VD78 well-formed subnets, or reduce with known equivalences (patterns), as SARA CFA does with the SARA/UCLA strong-reduction algorithm.
Avoid an ignorant commitment to a not verifiable vagueness with ill-structured subnets.
NN73 was a paper listed by Pe77. It is about macro-nets (Macro E-nets). E-nets are an extension of Petri nets - interpreted with data, and time. It is rather trivial to read NN73, for a Petri net case.