CP — Concurrent Programming 12. Petri Nets Prof. O. Nierstrasz Wintersemester 2005 / 2006.

Slides:



Advertisements
Similar presentations
8. Static Single Assignment Form Marcus Denker. © Marcus Denker SSA Roadmap  Static Single Assignment Form (SSA)  Converting to SSA Form  Examples.
Advertisements

1 SE-561 Formal Methods in Software Petri Nets - I.
Knowledge Based Synthesis of Control for Distributed Systems Doron Peled.
An Introduction to Petri Nets
Introduction to Petri Nets Hugo Andrés López
Petri Nets Section 2 Roohollah Abdipur.
Based on: Petri Nets and Industrial Applications: A Tutorial
8. Introduction to Denotational Semantics. © O. Nierstrasz PS — Denotational Semantics 8.2 Roadmap Overview:  Syntax and Semantics  Semantics of Expressions.
12. Common Errors, a few Puzzles. © O. Nierstrasz P2 — Common Errors, a few Puzzles 12.2 Common Errors, a few Puzzles Sources  Cay Horstmann, Computing.
ESE Einführung in Software Engineering 6. Modeling Objects and Classes Prof. O. Nierstrasz.
ESE Einführung in Software Engineering 7. Modeling Behaviour Prof. O. Nierstrasz.
Introduction to Software Engineering 7. Modeling Behaviour.
IE 469 Manufacturing Systems
CP — Concurrent Programming 5. Safety and Liveness Properties Prof. O. Nierstrasz Wintersemester 2005 / 2006.
CP — Concurrent Programming 8. Liveness and Asynchrony Prof. O. Nierstrasz Wintersemester 2005 / 2006.
Synthesis of Embedded Software Using Free-Choice Petri Nets.
10. Petri Nets Prof. O. Nierstrasz. Roadmap  Definition: —places, transitions, inputs, outputs —firing enabled transitions  Modelling: —concurrency.
Petri Nets Overview 1 Definition of Petri Net C = ( P, T, I, O) Places P = { p 1, p 2, p 3, …, p n } Transitions T = { t 1, t 2, t 3, …, t n } Input.
Object-Oriented Reengineering Patterns and Techniques Prof. O. Nierstrasz Prof. S. Ducasse T.
8. Introduction to Denotational Semantics. © O. Nierstrasz PS — Denotational Semantics 8.2 Roadmap  Syntax and Semantics  Semantics of Expressions 
6. Introduction to the Lambda Calculus. © O. Nierstrasz PS — Introduction to the Lambda Calculus 6.2 Roadmap  What is Computability? — Church’s Thesis.
12. Summary, Trends, Research. © O. Nierstrasz PS — Summary, Trends, Research Roadmap  Summary: —Trends in programming paradigms  Research:...
12. Common Errors, a few Puzzles. © O. Nierstrasz P2 — Common Errors, a few Puzzles 12.2 Common Errors, a few Puzzles Overview  Common errors … —Typical.
ESE Einführung in Software Engineering N. XXX Prof. O. Nierstrasz Fall Semester 2009.
© Oscar Nierstrasz ST — Smalltalk Basics 2.1 Change sets  Make sure your changes are logged to a new change set.
The Software Composition Group Prof. O. Nierstrasz
CP — Concurrent Programming 1. Introduction Prof. O. Nierstrasz Wintersemester 2005 / 2006.
13. Summary, Trends, Research. © O. Nierstrasz PS — Summary, Trends, Research Summary, Trends, Research...  Summary: functional, logic and object-oriented.
ESE Einführung in Software Engineering X. CHAPTER Prof. O. Nierstrasz Wintersemester 2005 / 2006.
7. Fixed Points. © O. Nierstrasz PS — Fixed Points 7.2 Roadmap  Representing Numbers  Recursion and the Fixed-Point Combinator  The typed lambda calculus.
9. Optimization Marcus Denker. 2 © Marcus Denker Optimization Roadmap  Introduction  Optimizations in the Back-end  The Optimizer  SSA Optimizations.
Metamodeling Seminar X. CHAPTER Prof. O. Nierstrasz Spring Semester 2008.
© Oscar Nierstrasz ST — Smalltalk Basics 2.1 Change sets  Make sure your changes are logged to a new change set.
ESE Einführung in Software Engineering X. CHAPTER Prof. O. Nierstrasz Wintersemester 2005 / 2006.
N. XXX Prof. O. Nierstrasz Thanks to Jens Palsberg and Tony Hosking for their kind permission to reuse and adapt the CS132 and CS502 lecture notes.
7. Fixed Points. © O. Nierstrasz PS — Fixed Points 7.2 Roadmap Overview  Representing Numbers  Recursion and the Fixed-Point Combinator  The typed.
12. Common Errors, a few Puzzles. © O. Nierstrasz P2 — Common Errors, a few Puzzles 12.2 Common Errors, a few Puzzles Sources  Cay Horstmann, Computing.
1 Formal Models for Transactions: Zero Safe Nets Roberto Bruni Dipartimento di Informatica Università di Pisa Models and Languages for Coordination and.
7. Fixed Points. © O. Nierstrasz PS — Fixed Points 7.2 Roadmap  Representing Numbers  Recursion and the Fixed-Point Combinator  The typed lambda calculus.
7. Liveness and Asynchrony Prof. O. Nierstrasz. Roadmap  Asynchronous invocations  Simple Relays —Direct invocations —Thread-based messages —Command-based.
12. Summary, Trends, Research. © O. Nierstrasz PS — Summary, Trends, Research Roadmap  Summary: —Trends in programming paradigms  Research:...
© S. Demeyer, S. Ducasse, O. Nierstrasz Chapter.1 MakeMoney Corp. C*O of MakeMoney Corp. Our Vision  We invest in software  We do not know software 
OORPT Object-Oriented Reengineering Patterns and Techniques X. CHAPTER Prof. O. Nierstrasz.
CP — Concurrent Programming X. CHAPTER Prof. O. Nierstrasz Wintersemester 2005 / 2006.
12. eToys. © O. Nierstrasz PS — eToys 12.2 Denotational Semantics Overview:  … References:  …
Petri Nets An Overview IE 680 Presentation April 30, 2007 Renata Kopach- Konrad.
A Usable Reachability Analyser Victor Khomenko Newcastle University.
An Introduction to Petri Nets Marjan Sirjani Formal Methods Laboratory University of Tehran.
CY2003 Computer Systems Lecture 7 Petri net. © LJMU, 2004CY2003- Week 72 Overview Petri net –concepts –Petri net representation –Firing a transition –Marks.
Numerical Methods Continuous Fourier Series Part: Continuous Fourier Series
Petri Nets Lecturer: Roohollah Abdipour. Agenda Introduction Petri Net Modelling with Petri Net Analysis of Petri net 2.
Modelling by Petri nets
Ch5: Software Specification. 1 Petri Nets  Introduced by C. Adams Petri in  Widely used in the modeling and analysis of computer systems.  Basic.
CSCI1600: Embedded and Real Time Software Lecture 11: Modeling IV: Concurrency Steven Reiss, Fall 2015.
School of Computer Science & Software Engineering
CAP 4800/CAP 5805: Computer Simulation Concepts
CP — Concurrent Programming 6. Liveness and Guarded Methods Prof. O. Nierstrasz Wintersemester 2005 / 2006.
Digital Ecosystems supporting growth and SMEs 1st cluster meeting Results and commitments 1st cluster meeting Results and commitments.
Open Access and Institutional Repositories, 10 July 2007, UKZN, Durban,,South Africa Metadata for institutional repositories: an introduction Pat Liebetrau.
Turing Machine Model Are there computations that no “reasonable” computing machine can perform? –the machine should not store the answer to all possible.
Technology of information systems Lecture 5 Process management.
Laurea Triennale in Informatica – Corso di Ingegneria del Software I – A.A. 2006/2007 Andrea Polini VIII. Specifications (II)
Victor Khomenko Newcastle University
Sketching Vocabulary Chapter 3.4 in Sketching User Experiences: The Workbook Drawing objects, people, and their activities.
Advantages of FSM Their simplicity make it easy for inexperienced developers to implement with little to no extra knowledge (low entry level)
Concurrent Systems Modeling using Petri Nets – Part II
CSCI1600: Embedded and Real Time Software
An Introduction to Petri Nets
Petri Net :Abstract formal model of information flow Major use:
CSCI1600: Embedded and Real Time Software
Presentation transcript:

CP — Concurrent Programming 12. Petri Nets Prof. O. Nierstrasz Wintersemester 2005 / 2006

© Oscar Nierstrasz CP — Petri Nets CP 12.2 Petri Nets Overview  Definition: —places, transitions, inputs, outputs —firing enabled transitions  Modelling: —concurrency and synchronization  Properties of nets: —liveness, boundedness  Implementing Petri net models: —centralized and decentralized schemes Reference:  J. L. Peterson, Petri Nets Theory and the Modelling of Systems, Prentice Hall, 1983.

© Oscar Nierstrasz CP — Petri Nets CP 12.3 Petri nets: a definition A Petri net C =  P,T,I,O  consists of: 1. A finite set P of places 2. A finite set T of transitions 3. An input function I: T  Nat P (maps to bags of places) 4. An output function O: T  Nat P A marking of C is a mapping m: P  Nat Example: P = { x, y } T = { a, b } I(a) = { x }, I(b) = { x, x } O(a) = { x, y }, O(b) = { y } m = { x, x } x b a y

© Oscar Nierstrasz CP — Petri Nets CP 12.4 Firing transitions To fire a transition t: 1. t must be enabled: m ≥ I(t) 2. consume inputs and generate output: m= m - I(t) + O(t) b a b a b

© Oscar Nierstrasz CP — Petri Nets CP 12.5 Modelling with Petri nets Petri nets are good for modelling:  concurrency  synchronization Tokens can represent:  resource availability  jobs to perform  flow of control  synchronization conditions...

© Oscar Nierstrasz CP — Petri Nets CP 12.6 Concurrency Independent inputs permit “concurrent” firing of transitions

© Oscar Nierstrasz CP — Petri Nets CP 12.7 Conflict Overlapping inputs put transitions in conflict a b Only one of a or b may fire

© Oscar Nierstrasz CP — Petri Nets CP 12.8 Mutual Exclusion The two subnets are forced to synchronize

© Oscar Nierstrasz CP — Petri Nets CP 12.9 Fork and Join

© Oscar Nierstrasz CP — Petri Nets CP Producers and Consumers producer consumer

© Oscar Nierstrasz CP — Petri Nets CP Bounded Buffers #occupied slots #free slots

© Oscar Nierstrasz CP — Petri Nets CP Reachability and Boundedness Reachability:  The reachability set R(C,m) of a net C is the set of all markings m’ reachable from initial marking m. Boundedness:  A net C with initial marking  is safe if places always hold at most 1 token.  A marked net is (k-)bounded if places never hold more than k tokens.  A marked net is conservative if the number of tokens is constant.

© Oscar Nierstrasz CP — Petri Nets CP Liveness and Deadlock Liveness:  A transition is deadlocked if it can never fire.  A transition is live if it can never deadlock. This net is both safe and conservative. Transition a is deadlocked. Transitions b and c are live. The reachability set is {{y}, {z}}. x a y z b c Are the examples we have seen bounded? Are they live?

© Oscar Nierstrasz CP — Petri Nets CP Related Models Finite State Processes  Equivalent to regular expressions  Can be modelled by one-token conservative nets The FSA for: a(b|c)*d a b c d

© Oscar Nierstrasz CP — Petri Nets CP Finite State Nets Some Petri nets can be modelled by FSPs u w a v x c b {u,w} {v,w} {u,x} {v,x} a ba b c Precisely which nets can (cannot) be modelled by FSPs?

© Oscar Nierstrasz CP — Petri Nets CP Petri nets are not computationally complete  Cannot model “zero testing”  Cannot model priorities a b c d Zero-testing Nets A zero-testing net: An equal number of a and b transitions may fire as a sequence during any sequence of matching c and d transitions. (#a ≥ #b, #c ≥ #d)

© Oscar Nierstrasz CP — Petri Nets CP Other Variants There exist countless variants of Petri nets Coloured Petri nets:  Tokens are “coloured” to represent different kinds of resources Augmented Petri nets:  Transitions additionally depend on external conditions Timed Petri nets:  A duration is associated with each transition

© Oscar Nierstrasz CP — Petri Nets CP Applications of Petri nets Modelling information systems:  Workflow  Hypertext (possible transitions)  Dynamic aspects of OODB design

© Oscar Nierstrasz CP — Petri Nets CP Implementing Petri nets We can implement Petri net structures in either centralized or decentralized fashion: Centralized:  A single “net manager” monitors the current state of the net, and fires enabled transitions. Decentralized:  Transitions are processes, places are shared resources, and transitions compete to obtain tokens.

© Oscar Nierstrasz CP — Petri Nets CP Centralized schemes In one possible centralized scheme, the Manager selects and fires enabled transitions. Concurrently enabled transitions can be fired in parallel. What liveness problems can this scheme lead to?

© Oscar Nierstrasz CP — Petri Nets CP Decentralized schemes In decentralized schemes transitions are processes and tokens are resources held by places: Transitions can be implemented as thread-per-message gateways so the same transition can be fired more than once if enough tokens are available. x y a b xy ab get()

© Oscar Nierstrasz CP — Petri Nets CP Transactions Transitions attempting to fire must grab their input tokens as an atomic transaction, or the net may deadlock even though there are enabled transitions! If a and b are implemented by independent processes, and x and y by shared resources, this net can deadlock even though b is enabled if a (incorrectly) grabs x and waits for y. a b x y

© Oscar Nierstrasz CP — Petri Nets CP Coordinated interaction A simple solution is to treat the state of the entire net as a single, shared resource: After a transition fires, it notifies waiting transitions. a b x y ab get() How could you refine this scheme for a distributed setting?

© Oscar Nierstrasz CP — Petri Nets CP What you should know!  How are Petri nets formally specified?  How can nets model concurrency and synchronization?  What is the “reachability set” of a net? How can you compute this set?  What kinds of Petri nets can be modelled by finite state processes?  How can a (bad) implementation of a Petri net deadlock even though there are enabled transitions?  If you implement a Petri net model, why is it a good idea to realize transitions as “thread-per-message gateways”?

© Oscar Nierstrasz CP — Petri Nets CP Can you answer these questions?  What are some simple conditions for guaranteeing that a net is bounded?  How would you model the Dining Philosophers problem as a Petri net? Is such a net bounded? Is it conservative? Live?  What could you add to Petri nets to make them Turing- complete?  What constraints could you put on a Petri net to make it fair?

© Oscar Nierstrasz CP — Petri Nets CP License > Attribution-ShareAlike 2.5 You are free: to copy, distribute, display, and perform the work to make derivative works to make commercial use of the work Under the following conditions: Attribution. You must attribute the work in the manner specified by the author or licensor. Share Alike. If you alter, transform, or build upon this work, you may distribute the resulting work only under a license identical to this one. For any reuse or distribution, you must make clear to others the license terms of this work. Any of these conditions can be waived if you get permission from the copyright holder. Your fair use and other rights are in no way affected by the above. Attribution-ShareAlike 2.5 You are free: to copy, distribute, display, and perform the work to make derivative works to make commercial use of the work Under the following conditions: Attribution. You must attribute the work in the manner specified by the author or licensor. Share Alike. If you alter, transform, or build upon this work, you may distribute the resulting work only under a license identical to this one. For any reuse or distribution, you must make clear to others the license terms of this work. Any of these conditions can be waived if you get permission from the copyright holder. Your fair use and other rights are in no way affected by the above.