See discussions, stats, and author profiles for this publication at: https://www.researchgate.

net/publication/220808530

Specific proposals for the use of petri nets in a concurrent programming course

Conference Paper in ACM SIGCSE Bulletin · September 2002

DOI: 10.1145/637610.544463 · Source: DBLP

CITATIONS READS
2 1,560

1 author:

Joao Paulo Barros

Polytechnic Institute of Beja
121 PUBLICATIONS 946 CITATIONS

SEE PROFILE

All content following this page was uploaded by Joao Paulo Barros on 27 May 2014.

The user has requested enhancement of the downloaded file.

 Specific Proposals for the Use of Petri Nets
in a Concurrent Programming Course
João Paulo Barros
Instituto Politécnico de Beja,
Escola Superior de Tecnologia e Gestão
Rua Afonso III, n.º 1
7800-050 Beja, PORTUGAL
+351 284 311 543
[email protected]

ABSTRACT programming, have significant difficulty in visualizing concurrent

Concurrency is a difficult subject to teach and learn. This paper systems behaviour. To overcome this, we soon convinced
presents a set of recipes for the use of Petri nets as a teaching aid ourselves that a multiple view approach to system modelling
of some fundamental concurrency concepts, in the context of an would be the one that better could assist student understanding.
introductory concurrent programming course. Classroom Besides we believe that a concurrent programming course, due to
experience clearly demonstrates this usage of Petri nets improves concurrent programming intrinsic difficulty, is probably the best
students understanding of concurrency concepts. place to convey the necessity of good software engineering
practices, namely the ones directly related to the software life
cycle. These include: analysis, design, verification and/or testing
Categories and Subject Descriptors in the design phase, good coding practices and project
K.3.2 [Computers and Education]: Computer and Information documentation. Fortunately a book that applies these ideas
Science Education --- Computer science education; D.2.2 already exists [3], and we have based our concurrent
[Software Engineering]: Design Tools and Techniques --- Petri programming course on it since 1999. For each section, the book
nets, D.2.4 [Software Engineering]: Software/Program follows the sequence: concepts, models and implementation. It
Verification --- Formal method, Model checking, Validation; clearly and efficiently presents modelling and verification
D.1.3 [Programming Techniques]: Concurrent Programming; techniques using a simple process algebra language. The language
is named FSP (Finite State Processes) and was developed for
General Terms pedagogical purposes. It also contains an associated tool for
Documentation, Languages, Design, Verification. specifying and analysing the FSP models expressed in textual
form. Starting from the FSP model, the tool (named LTSA for
Keywords Labelled Transition System Animator) is capable of graphically
Introductory course, FSP, LTSA, process algebra, state machines. display the processes as state machines. It also generates the state
machine resulting from the processes parallel composition. It
allows progress and safety properties verification, as well as
1. INTRODUCTION model execution through the use of an interactive simulator
Concurrency courses have a very broad variability. They can be where, in each execution step, the user selects one of the enabled
taught in different places in the curriculum, typically in operating actions. This usage is proposed in the context of a software life
systems or programming language courses, but also in software cycle encompassing analysis, design, verification and coding.
engineering courses and distributed databases courses. They can Finally, it also proposes a simple but effective technique to
be taught to novice students but, more frequently, to intermediate translate FSP models to concurrent programs in the Java
or advanced students. They can use different tools and languages. Programming language.
Yet they all have in common the necessity of teaching the The approach followed in the book has proven quite effective. Yet
fundamental concurrency concepts. In our experience, most we have found that student learning, namely the understanding of
students, and particularly the ones already trained in sequential some fundamental concepts can be significantly improved by the
simultaneous presentation and use of Petri net models [5].

Permission to make digital or hard copies of all or part of this work for 2. THE COURSE
personal or classroom use is granted without fee provided that copies are
not made or distributed for profit or commercial advantage and that
The course follows the referred book [3] which is used as the
copies bear this notice and the full citation on the first page. To copy main reference. As such, in each course section we also present
otherwise, or republish, to post on servers or to redistribute to lists, concepts prior to models and these prior to coding. We present
requires prior specific permission and/or a fee. UML class and object diagrams, FSP and Java concurrent
ITiCSE’02, June 24-26, 2002, Aarhus, Denmark. constructs. Java is used due to its current popularity and included
Copyright 2002 ACM 1-58113-499-1/02/0006…$5.00. support for concurrency, namely monitors.

165
2.1 Assessment 3.1 Synchronization and Deadlock
Student assessment is based on a semester long project and an Synchronization is clearly visualized in almost any Petri net. Here
open book written exam. we propose the use of Petri nets to visualize a deadlock initial
state. This section uses the FSP model from an exercise proposed
The project implies analyse, design and coding of a simple
in [3] as an example of the added advantage on the use of Petri
concurrent system containing a few processes. These are coded as
nets for better understanding of concurrency concepts. In this case
Java Threads. Students are required to use UML, FSP, Petri nets
the concepts are synchronisation and a deadlock resulting from a
and Java. We also encourage the generation of project
“wait-for cycle”. The FSP model, containing three primitive
documentation, namely UML class diagrams and source code
processes (“Alice”, “Bob” and “Chris”) and one composite
documentation.
process (“S”), is the following:
The written exam presents some simple concurrent systems and Alice = (call.bob -> wait.chris -> Alice).
asks for FSP specifications and/or Petri nets models. It also Bob = (call.chris -> wait.alice -> Bob).
explores safety and liveness properties. Chris = (call.alice -> wait.bob -> Chris).

||S = (Alice || Bob || Chris) /{call/wait}.

2.2 Course Structure
Each necessary synchronisation is specified through the use of the
Each course section has the following structured sequence:
same action (same name) in more than one state machine. The
1. Concepts operator / specifies sets of pairs for action name substitution. In
2. Relevant FSP constructs. the example above, “wait” is substituted by “call”. That implies,
for example, that “wait.chris” will be replaced by “call.chris”,
3. Relevant Petri net constructs.
specifying, in this way, synchronization between processes
4. Construction of the FSP model and analysis of its “Alice” and “Bob”. The LTSA tool translates each process
behaviour using the LTSA tool. modelled in FSP to a graphical representation of a state machine
5. Construction of the Petri net model from the FSP (Figure 1).
specification and/or from the state machines generated
by the LTSA tool.
6. Simulation of the Petri net model.
7. Translation to a UML class or object diagram.
8. Coding of the Java program.
Points 3, 5 and 6 constitute the proposed additions to the
methodology in [3].

3. THE USE OF PETRI NETS

As presented in the previous section, Petri nets are presented
along the course, together with the corresponding FSP constructs. Figure 1. State machines generated by the LTSA tool.
In this way, students are able to understand the similarities of both
notations and also the advantages and disadvantages as applied to
each concept. Most notably students are forced to separate the The tool can generate composite processes resulting from the
concepts from their expression in one particular modelling tool. parallel composition of those state machines. Yet, in this
So that the overhead of learning yet another notation is no particular example, the deadlock does not allow that visualization,
obstacle to the intended course objectives, low-level Petri nets as the initial state is a deadlock state. This fact is not immediately
were preferred against other Petri nets classes, namely high-level obvious. In fact the explanation of this situation is proposed as the
nets [2], which, although more powerful, would require too much exercise to the student.
course time. Ordinary Petri nets also have the added and very
The Petri net model allows a much more intuitive perception of
significant advantage of mapping very nicely to FSP models. In
the dependencies (synchronisations) among processes. For that we
addition a simple and friendly Petri net tool was used: Visual
ask the student to translate the state machines into Petri nets and
Object Net++. This and many others can be found in the Petri nets
group the synchronising actions, which have become Petri net
tools database [4]. Students react very favourably to the use of
transitions (Figure 2). This is a very simple process quickly
Petri net tools that allow the graphical editing and simulation
grasped by students. Them we merge the grouped transitions and
(token-player) of Petri net models. Based on student reactions, we
obtain the composite process model as a single Petri net (Figure
are absolutely convinced that the use of at least one tool is
3).
necessary for a good and motivating study of Petri nets. Next sub-
sections present, in detail and by means of example problems, the
proposed usage of Petri nets. This usage emphasizes the relation
between Petri nets and FSP models.

166
 wait.bob Consider the following FSP model that specifies a simple
call.bob semaphore with states red and green.
CLOCK = (tick -> CLOCK).
call.bob
CLOCKL(N = 2) = (start -> LG[0]),
LG[lg:0..6] = (when (lg < N) tick -> LG[lg+1]
wait.chris
|when (lg == N) long_tick ->
CLOCKL).
|| LONG_CLOCK = (CLOCK || CLOCKL).
call.chris wait.chris
SEMAPHORE_GREEN = (change_to_red ->
call.chris
SEMAPHORE_RED),
SEMAPHORE_RED = (change_to_green ->
SEMAPHORE_GREEN).
The semaphore is controlled by a process “CLOCK”, that
wait.alice generates an action named “tick”, and a “CLOCKL” process, that
call.alice
generates a “long_tick” action after two “tick”. The process
wait.alice “LONG_CLOCK” is a composite of “CLOCK” and “CLOCKL”.
call.alice
The “SEMAPHORE_GREEN” process specifies the light change.
The timing is to be imposed by the composition of
“SEMAPHORE_GREEN” with one or more “CLOCK” and/or
“LONG_CLOCK” processes. The semaphore should change to
wait.bob
red after one “tick” in green and change to green after one
Step 1/3: Translation Step 2/3: Grouping of “long_tick” in red.
from state-machines to synchronized
Petri nets notation transitions. A first attempt could be:
||SEMAPHORE_TIMED = (SEMAPHORE || LONG_CLOCK)
Figure 2. From parallel state machines to Petri nets. The /{change_to_red/tick,
figure illustrates the first two of a total of three steps. change_to_green/long_tick}.
A brief look at this Petri net makes clear that the system is Unfortunately, this does not work. The “change_to_red” action
deadlocked as no transition can fire. This results from each will consume one “tick” that should be used by the
transition dependency on an unmarked place on the right. “change_to_green” (“long_tick”). As such the semaphore will be
bob
one single “tick” in the red state instead of two. To avoid this
problem we can try to add one CLOCK process to the composite:
||SEMAPHORE_TIMED = (SEMAPHORE_GREEN ||
LONG_CLOCK ||
CLOCK)
/{change_to_red/tick,
chris change_to_green/long_tick}.
This has a new, more subtle, problem: we have one more process
“CLOCK”, besides the one “inside” “LONG_CLOCK”, but it
remains synchronized with the “LONG_CLOCK”. As such we
have not made any progress yet. This is much more obvious in the
alice Petri net model (Figure 4).

CLOCK

Step 3/3: Merging of

change_to_red = tick
grouped (synchronized)
transitions.

RED
Figure 3. From parallel state machines to Petri nets. The GREEN
figure illustrates the last of a total of three steps. SEMAPHORE_GREEN
Next we present a more elaborate example emphasizing process change_to_green = long_tick
composition understanding.
2 2

3.2 Process Composition LONG_CLOCK

Process composition can lead to some perplexities due to
unobvious action synchronisation. Petri nets uncover these Figure 4 Petri net for the FSP model where CLOCK and
complexities in a visual and dynamic way. The following example LONG_CLOCK synchronize in the action tick.
illustrates just that.

167
It is enough to observe that after the firing of the transition interleaving and, by consequence, the state explosion problem,
associated to actions “change_to_red” and “tick”, the net will but it has the cost of making unclear the dependencies between
deadlock as no transition will be enabled. Students can observe processes, namely their synchronisations. Even the parallelism is
this behaviour using the mentioned Petri net tool, or any other not clear as the interleaving hides it under the states representing
tool that allows token-game graphical simulation, will be combinations of more than one state in the original state
adequate. machines. By contrast, a Petri net allows a clear visualization not
At this point most students will realize by themselves that the only of the initial state machines (which are just a particular case
problem is the “use” of process CLOCK by process of a Petri net) but also of the parallel composition and respective
LONG_CLOCK. From this a possible solution is quite obvious: synchronisations.
LONG_CLOCK should use a different CLOCK (labelled “a” in
a:CLOCK
the following code):
||SEMAPHORE_TIMED = (SEMAPHORE_GREEN ||
LONG_CLOCK ||
a:CLOCK)
/{change_to_red/a.tick, change_to_red = a.tick = start
change_to_green/long_tick}.
GREEN RED

The corresponding Petri net is even more readable (Figure 5).

Yet, its simulation, reveals that the independency between SEMAPHORE_GREEN 2
“CLOCK”s allows the evolution of “LONG_CLOCK” before the change_to_green = long_tick

semaphore gets to “RED” state. Namely, a “tick” can occur while 2

not yet in the “RED” state. That allows the transition to
“GREEN” after only one tick in the “RED” state. To avoid this
we must start “LONG_CLOCK” on transition to RED: tick
||SEMAPHORE_TIMED = (SEMAPHORE_GREEN ||
LONG_CLOCK ||
a:CLOCK) LONG_CLOCK
/{change_to_red/{a.tick,
start},
CLOCK
change_to_green/long_tick}.
Figure 6. Petri net for FSP model with clock restart on change
a:CLOCK to RED.
3.3 Conflict and Starvation
Petri nets provide an extremely readable model of the classic
dining philosophers problem [1]. Figure 7 presents a simplified
change_to_red = a.tick specification that avoids deadlock by imposing an atomic
GREEN
acquisition of the respective forks by each philosopher. The
RED
concepts of conflict and starvation are absolutely clear in a Petri
net simulation. We can almost “see” the philosophers trying to get
SEMAPHORE_GREEN their forks. A simple modification allowing the acquisition of
change_to_green = long_tick each fork in separate, by each philosopher, also allows deadlock
visualization
2 2

4. EVALUATION
The presented examples were used in one edition of the referred
tick
introductory concurrent programming course; two previous
editions had used preliminary versions of those same examples. In
the course we had 16 students. About half the students had one
LONG_CLOCK year experience using the Java language in an academic setting;
the others had zero or negligible experience programming Java or
CLOCK any other object-oriented programming language. Most of them
had been exposed to concurrent programming only in an
Figure 5 Petri net for FSP model with one more clock. operating systems course through the study of trivial concurrent
The final Petri net only starts the LONG_CLOCK process on programs written in the C programming language and using
arrive to state RED (Figure 6). UNIX system calls.
Note that the composite state machine, generated by the LTSA
tool, contains all the interleavings allowed by the
synchronisations. This is very useful to understand the concept of

168
 The inquiry clearly showed that students found the addition of
Petri nets useful particularly in the understanding of concepts.
They did not found Petri nets models to be easier to build than
FSP models, but the majority found easier to start by the Petri net
model as opposed to the FSP model. Also, most of the students
found that the Petri net model helped them to understand the Java
programs. These results confirmed our feedback from the class,
namely that the presented usage of Petri nets improves students
understanding of concurrent programs and concurrency concepts.

5. CONCLUSION AND FUTURE WORK

We have found the Petri net formalism to be particularly valuable
in the understanding of process composition, synchronization,
deadlock, conflict and starvation. The presented examples
demonstrate their usefulness as an aid in student understanding of
these concepts. Students particularly valued the extra insight
provided by the Petri nets models and animated simulations. We
notice that the understanding of all studied systems always
improves when Petri net models are studied together with FSP
algebraic models. In this sense we intend to increase the coupling
between FSP models and Petri net models. One way to
accomplish this will be to create additional examples of Petri net
modelling and respective relation to FSP models. Another will be
Figure 7. Petri net for the dining philosophers problem. the developing of an automatic translation tool from FSP to Petri
nets. This will allow a faster presentation of Petri nets in
classroom and significantly help the student when self-studying
So as to get more rigorous feedback about the use of Petri nets a
questionnaire was given to the 16 students; 10 of them answered.
The questionnaire used a Likert scale: from 1 (strongly disagree) 6. ACKNOWLEDGEMENTS
to 5 (strongly agree). The answers to the questions relevant to the The author thanks Luis Gomes, from Faculdade de Ciências e
evaluation of the presented Petri net usage are summarized in Tecnologia of Universidade Nova de Lisboa, and the three
Table 1. anonymous reviewers for their valuable comments on this paper.

7. REFERENCES
Table 1. Answers to the questionnaire given to students.
[1] Ben-Ari, M. “Principles of Concurrent Programming”,
Average in Prentice-Hall, 1982.
Question a Likert
scale (1-5) [2] Jensen, K. e Rozemberg(Eds.) High-level Petri Nets:Theory
and Application, Springer-Verlag, 1991.
Petri nets allowed a better understanding of process 4.3
composition [3] Magee, Jeff, Kramer, Jeff, “Concurrency State Models and
Petri nets allowed a better understanding of the starvation 4.4
Java Programs”, John Wiley & Sons, 1999.
and deadlock concepts
[4] Petri Net Tools, http://www.daimi.au.dk/PetriNets/tools/.
Overall, Petri nets allowed a better understanding of 4.4
concurrent systems operation [5] Reisig, Wolfgang, “Elements of Distributed Algorithms –
The construction of FSP models PLUS Petri nets, helped Modeling and Analysis with Petri Nets”, Springer, 1998.
4.4
the understanding of concepts and concurrent systems
Petri net models are easier to understand than FSP models 3.8

Petri net models are easier to build than FSP models 3.3

It is easier to start by doing the Petri net model rather than 3.7
by the FSP model
Petri net models make Java programs easier to 3.8
understand.

169

View publication stats