Petri nets — Mission
Sections
Reading settings
Natural voice recorded for this course, the same in every browser.
No voice for this language in this browser.
More voices
Code and English terms
Off: the page’s voice reads everything, with no pause between two voices.
No voice for this language in this browser.
More voices
More voices: Microsoft Edge has natural online voices, and Windows (Settings › Time & language › Speech), macOS and Android install others.
Why I’m learning this
Section titled “Why I’m learning this”I can draw a state machine. I have written them in C# with an enum and a switch, and in Java with a state pattern, and they work as long as the system does one thing at a time. Then two things happen at once. Two threads take two locks in two orders. A Channel<T> fills up and the producer blocks for ever. A workflow has three branches and nobody can say whether all of them can finish.
A state machine cannot say any of that, because it has one current state, and the thing I am modelling has several. What I want is a model whose state is a distribution: so many requests in the queue, so many workers busy, one lock held. A Petri net is exactly that, and it comes with a small body of mathematics that answers questions I currently answer with load tests and hope:
- can this queue overflow? Not “did it overflow last Tuesday” — can it, ever, under any interleaving;
- can this system deadlock? And if it can, what is the shortest sequence that gets there;
- is this workflow going to finish? From every state it can get into, not just the happy path.
Those three questions are decided by a program in this course, on nets that model real things: a bounded buffer, a mutual exclusion, two locks taken in opposite orders.
Who this course is for
Section titled “Who this course is for”You are a C# or Java developer. You have written concurrent code and modelled processes with state machines. You do not need any mathematics beyond adding vectors and multiplying a matrix by one; the course introduces what it uses, and the first matrix appears in lesson 2 only because it makes something concrete easier.
The concurrency lessons lean on what you already know. Lesson 7 takes the backpressure of lessons 6 to 9 of the Advanced C# course — channels, TPL Dataflow, Rx — and models it instead of measuring it. Lesson 14 starts the repository dogfooding with one bounded C# lifecycle and an agent-lane lock; RabbitMQ and Kubernetes remain explicit follow-up experiments.
The running example
Section titled “The running example”One producer, one consumer, and a buffer of two slots. Three places hold the state of the producer, the consumer and the buffer; four transitions are the events. Nothing is a “current state”: the marking says where every token is at once.
flowchart LR ready(("ready<br/>●")) produced(("produced")) free(("free<br/>● ●")) full(("full")) waiting(("waiting<br/>●")) taken(("taken")) produce["produce"] deposit["deposit"] take["take"] consume["consume"] ready --> produce produce --> produced produced --> deposit free --> deposit deposit --> full deposit --> ready full --> take waiting --> take take --> taken take --> free taken --> consume consume --> waitingThat net has twelve reachable markings, it never deadlocks, and the place free is the whole reason the buffer cannot overflow — remove it, and the set of reachable markings becomes infinite. Lessons 1 to 4 prove all three statements, and lesson 5 proves the first one again without looking at a single marking.
By the end of this course, I will be able to
Section titled “By the end of this course, I will be able to”- read and draw a Petri net, and say what its marking means in the system it models;
- write the incidence matrix of a net, and know what the state equation does and does not decide;
- build a reachability graph, and a coverability tree when the graph is infinite;
- decide boundedness, safeness, liveness, deadlock-freedom, reversibility and persistence, and say which of them a given system actually needs;
- compute place and transition invariants, and use one as a proof that holds for every reachable marking;
- recognise state machines, marked graphs and free-choice nets, and use the theorems that come with them;
- model mutual exclusion, producer/consumer, readers/writers and the dining philosophers, and compare the models with the C# and Java constructs they stand for;
- use coloured, timed and stochastic nets, and know what each extension costs in analysis;
- check a workflow for soundness, and translate between BPMN and workflow nets;
- exchange nets with TINA, LoLA, CPN Tools, GreatSPN and TAPAAL through PNML;
- model parts of the systems in this repository, and say honestly what the model found and what it missed;
- know where the formalism stops: what is undecidable, what is decidable but hopeless, and what to reach for instead.
Outline
Section titled “Outline”Journal: what I tried, what surprised me, what I still need to verify.
Resources
Section titled “Resources”- Petri Nets World, the community hub, with its tools list and its bibliographies
- Tadao Murata, Petri nets: Properties, analysis and applications, Proceedings of the IEEE 77(4), April 1989, pages 541–580, doi:10.1109/5.24143 — the survey this course quotes most often
- Wolfgang Reisig, Understanding Petri Nets, Springer, 2013, doi:10.1007/978-3-642-33278-4
- PNML, the Petri Net Markup Language, standardised as ISO/IEC 15909-1:2019 (concepts), ISO/IEC 15909-2:2011 (transfer format) and ISO/IEC 15909-3:2021 (extensions)
- Tools: TINA, LoLA, CPN Tools, GreatSPN, TAPAAL, Snoopy, PIPE
- The Model Checking Contest, where those tools are run against each other on a public set of nets every year
- Source code of this course:
code/petri-nets