Information Technology Reference
In-Depth Information
13.4.3
Modeling PIndex with Colored Petri Nets
13.4.3.1
Model Design
As discussed in Section 3, PIndex is scalable through PGs operating
independently and concurrently. However, although Petri nets have
been designed with concurrency in mind, running multiple instances that
interact with each other is not a part of Petri nets, although one may
include a combination of many Petri nets into a single Petri net to mimic
multiple instances and derive a mathematical model. This would not suit
the needs to model PIndex since (1) the number of PGs would be i xed,
i xing the size of the network to be simulated, disabling the model in
investigating PIndex's scalability; and (2) creating a i xed model will limit
its l exibility in investigating different network and routing conditions,
such as forcing a certain type of PG grouping using a node probability of
failure as a metric, which would have to rewrite the CPN model and
implementation.
Due to the multiple PGs nature of PIndex, representing a PG as a thread
would take advantage of their parallel execution to produce an object-
orientated CPN simulation model, which enables multiple instances of a
PG to run concurrently, truly modeling PIndex in a multinetwork distri-
bution (PIndex over many independent sites). Not only could one set each
thread with a priority, but this further gives an advantage in that PGs may
have a higher priority than the simulated clock, ensuring that all required
tasks are executed before the clock turns over. In addition the use of
threads allows the model to follow and act in a more parallel manner,
rel ecting real-life situations while conforming to the real-life paradigm,
with only ever one instance of a PG created. Note that each issued state
has a time stamp (start and stop) relative to the simulated clock. Having
instantiated these threads, the colored tokens (nodes) are processed as
objects. This means that in order to vary the network population, we only
need to change the number of token objects created.
13.4.3.2
Model Implementation
PIndex has many states when placed in a real working environment.
Before a CPN model can be established, i rstly each state must be recog-
nized. In the case of PIndex, a token represents a computing node that has
colors for different states as shown in Table 13.1 .
From the description given previously, a generic l ow chart of PIndex is
produced as shown in Figure 13.6 , from which our CPN model is derived
as shown in Figure 13.7 . When a token is i red it leaves the “start” place
and transits to the “submit a task (color)” place from which an inhibitor
is placed to the next stage if the “buffer” is occupied. If so, the token
will transit to the “buffer” place, otherwise the transition is made to the
 
Search WWH ::




Custom Search