1. CSCI1600: Embedded and Real Time Software
Lecture 13: Modeling IV: Concurrency
Steven Reiss, Fall 2016
Took too long to cover the basics. Didn’t get into the analysis portion. Think about covering analysis later on when we do verification. Either that or shortening the first part (there is considerable duplication).

2. Statecharts What is missing
Timing information for real time analysis
Performance evaluation
Synchronization information between tasks
How to model synchronization properties of a system
To understand what is happening
To reason about those properties
To prove safety (e.g. no deadlock)
Lecture 13: Modeling Concurrency
8/1/2019

3. Petri Nets Created in 1962 by Carl Petri
Mathematical tool for studying communication between automata
With a graphical representation
With a mathematical underpinning
Later tools (CSP, CCS, …) are more language oriented
Data flow languages are a generalization
Utility of Petri Nets
Modeling and studying synchronization
Modeling and studying asynchronous behaviors
Modeling and studying resource sharing
Lecture 13: Modeling Concurrency
8/1/2019

4. Petri Net Usage Good fit for embedded systems They remain widely used
Model communication in FSAs
They remain widely used
Communication protocols
Manufacturing systems
Sequence controllers
Software systems
Mathematical framework can be used for
Performance evaluation (not the best notation for this)
Scheduling problems (okay, but not preferred)
Reliability, safety, boundedness, liveness
Lecture 13: Modeling Concurrency
8/1/2019

5. Motivation Transitions are as important as states
Or More So
Both involve labels, actions, etc.
Represent both transitions and states as nodes
With different notations
Use arcs just to represent connections
States actually represent preconditions to a transition
Result of a transition is a set of postconditions
Represented by a state
Lecture 13: Modeling Concurrency
8/1/2019

6. Petri Net Components Bipartite graph Places = states Transitions Arcs
(Labeled) circles
Transitions
(Labeled) bars
Arcs
P -> T : preconditions to a transition
T -> P : postconditions to a transition
Can be integer-weighted (multiple instances of same arc)
No P -> P, T -> T arcs
Lecture 13: Modeling Concurrency
8/1/2019

7. Petri Net Tokens Each place can hold 0 or more tokens
Dots in the circle
Indicate precondition is true
State is active
Mapping of places to #tokens
Is a marking
Lecture 13: Modeling Concurrency
8/1/2019

8. Dynamics of Petri Nets
Petri nets are interesting for their dynamic behavior
Not their static description
Tokens move around according to fixed rules
Enabling rule : when a transition can fire
Firing rule : what happens when a transition fires
Lecture 13: Modeling Concurrency
8/1/2019

9. Enabling Rule
A transition T is enabled if each input place P of T contains at least the number of tokens equal to the weight of the arc connecting P to T
Lecture 13: Modeling Concurrency
8/1/2019

10. Firing Rule
An enabled transition may or may not fire depending on the interpretation
Only one at a time, fairness, nondeterminism, priorities
The firing of an enabled transition T removes from each input place P the number of tokens equal to the weight of the directed arc from P to T
It also deposits in each output place P’ the number of tokens equal to the weight of the directed arc connecting T to P.
Lecture 13: Modeling Concurrency
8/1/2019

11. Example: In a Restaurant
Waiter
free
Customer 1
Customer 2
Take
order
Order
taken
Tell
kitchen
wait
Serve food
eating
Lecture 13: Modeling Concurrency
8/1/2019

12. Petri Net Extensions Can add negation (absence of a token)
Can limit the number of tokens on a place
Effectively an output condition on a transition
Can have different types of tokens
Pure : no self loops
No place is input and output of a single transition
All these are equivalent to standard Petri Nets
Choosing transitions to fire
Nondeterministic, one at a time
Nondeterministic, set of non-conflicting transitions
Can add priorities, round-robin, …
Lecture 13: Modeling Concurrency
8/1/2019

13. PN models of key characteristics
Precedence relation:
Parallel processes:
Alternative processes:
Synchronization:
Lecture 13: Modeling Concurrency
8/1/2019

14. PN models of key characteristics
Buffer of finite capacity (4):
FIFO system:
Lecture 13: Modeling Concurrency
8/1/2019

15. PN models of key characteristics
Shared resources:
Lecture 13: Modeling Concurrency
8/1/2019

16. PN models of key characteristics
Dedicated machine:
Shared machine:
Lecture 13: Modeling Concurrency
8/1/2019

17. Concurrency
Independent inputs permit “concurrent” firing of transitions 
Lecture 13: Modeling Concurrency
8/1/2019

18. Only one of a or b may fire
Conflict
Overlapping inputs put transitions in conflict a b b
Only one of a or b may fire 
Lecture 13: Modeling Concurrency
8/1/2019

19. Mutual Exclusion  The two subnets are forced to synchronize 8/1/2019
Lecture 13: Modeling Concurrency
8/1/2019

20. Fork and Join
Lecture 13: Modeling Concurrency
8/1/2019 

21. Producers and Consumers
Lecture 13: Modeling Concurrency
8/1/2019 

22. Bounded Buffers  #occupied slots #free slots 8/1/2019
Lecture 13: Modeling Concurrency
8/1/2019

23. Example: Mutli-Robot System
Two robot arms can pick and place items in common workspace
Only one can access the workspace at a time
Modeling mutual exclusion
There is a buffer with limited space for products
One robots adds to the buffer
The other removes from it
Modeling producer consumer
Robots can also work outside the workspace
Lecture 13: Modeling Concurrency
8/1/2019

24. Robot Model P1, P4 : Robot performing tasks outside the work space
P2, P5: Robot waiting for access to the work space
P3, P6: Robot performing task in the common workspace
P7: Mutual exclusion
P8: Empty position in buffer
P9: Full position in buffer
Draw this on the board in pieces, i.e. P1, P4 to begin with. Then P2, P5; then P3, P6 – all with transitions between them
Then add P7 to show mutual exclusion: Add a token there
Then add P8 indicating hole or empty position in the buffer
Then add P9 indicating a used of full position in the buffer
Finally add 3 tokens to P8
Simulate what is happening
Lecture 13: Modeling Concurrency
8/1/2019

25. Lecture 13: Modeling Concurrency
8/1/2019

26. Example: Dining Philosophers
Lecture 13: Modeling Concurrency
8/1/2019

27. Petri Nets Reachability
Can a Petri net reach a specific state
What might you be interested in
Reach = there exists a sequence of firings from M0 to Mx
The set of markings reachable from M0 is the reachability set
R(M0)
Lecture 13: Modeling Concurrency
8/1/2019

28. Petri Net Properties
A Petri Net is k-bounded if the number of tokens in any place P is always <= k for every reachable marking
Why is this important
Might want different k’s for different states
A Petri Net is safe if it is 1-bounded
A Petri Net is conservative if the number of tokens is conserved
Does not require the same number of tokens all the time
Tokens have different weights in different states
Lecture 13: Modeling Concurrency
8/1/2019

29. Petri Net Properties A Petri Net is live if it is deadlock free
No reachable state that has no subsequent states
But could deadlock only part of the Petri Net
From any state reachable from M0, it is possible to fire any transition in the Petri net
Sufficient, not necessary (why)
Can quantify various degrees of liveness
Lecture 13: Modeling Concurrency
8/1/2019

30. Petri Net Properties
A Petri Net is reversible if for every marking M in R(M0), M0 is reachable from M
Error recovery
Could use a different state other them M0
Lecture 13: Modeling Concurrency
8/1/2019

31. Proving Properties Petri nets are inherently finite
Construct a graph of all possible markings
Flag states that are duplicates
Can then convert this to a tree
Can handle unbounded token counts
Use ω to represent infinity
ω + n = ω, ω – n = ω
Can detect from the tree when a count can be arbitrary – then replace with ω
Overall graph / tree is finite
Lecture 13: Modeling Concurrency
8/1/2019

32. Proving Properties Given the finite coverability tree
Proving properties is easy
Just check the property holds in each tree node
Can be done mechanically
Lecture 13: Modeling Concurrency
8/1/2019

33. Project If department is buying the parts
Create a complete shopping list (where/product/…)
Note that I have some items from previous years
Get it approved by TA or Professor
Take it to Kathy Kirman (Room 572)
If you need little parts, just come and ask for them
Resistors, transistors, diodes, lamps, wire, ICs, …
Also available in the IOT lab
Can borrow more expensive items for experimentation
Lecture 13: Modeling Concurrency
8/1/2019

34. Homework Do exercise 6.7 using Petri nets Read 2.4
Lecture 13: Modeling Concurrency
8/1/2019