CSCI1600: Embedded and Real Time Software Lecture 13: Modeling IV: Concurrency Steven Reiss, Fall 2017 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).

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 11/27/2018

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 11/27/2018

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 11/27/2018

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 11/27/2018

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 11/27/2018

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 11/27/2018

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 11/27/2018

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 11/27/2018

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 11/27/2018

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

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 (colors) 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 11/27/2018

PN models of key characteristics Precedence relation: Parallel processes: Alternative processes: Synchronization: Lecture 13: Modeling Concurrency 11/27/2018

Concurrency Independent inputs permit “concurrent” firing of transitions  Lecture 13: Modeling Concurrency 11/27/2018

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 11/27/2018

Fork and Join Lecture 13: Modeling Concurrency 11/27/2018 

PN models of key characteristics Buffer of finite capacity (4): FIFO system: Lecture 13: Modeling Concurrency 11/27/2018

Producers and Consumers Lecture 13: Modeling Concurrency 11/27/2018 

Bounded Buffers  #occupied slots #free slots 11/27/2018 Lecture 13: Modeling Concurrency 11/27/2018

PN models of key characteristics Shared resources: Lecture 13: Modeling Concurrency 11/27/2018

Mutual Exclusion  The two subnets are forced to synchronize Lecture 13: Modeling Concurrency 11/27/2018

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 Draw next slide 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 11/27/2018

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 11/27/2018

Lecture 13: Modeling Concurrency 11/27/2018

Example: Dining Philosophers Lecture 13: Modeling Concurrency 11/27/2018

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 11/27/2018

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 11/27/2018

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 11/27/2018

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 11/27/2018

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 11/27/2018

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 11/27/2018

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 11/27/2018

Homework Do exercise 6.7 using Petri nets Read 2.4 Lecture 13: Modeling Concurrency 11/27/2018