csci1600: embedded and real time software lecture 11: modeling iv: concurrency steven reiss, fall...

22
CSCI1600: Embedded and Real Time Software Lecture 11: Modeling IV: Concurrency Steven Reiss, Fall 2015

Upload: dwayne-poole

Post on 18-Jan-2016

218 views

Category:

Documents


0 download

TRANSCRIPT

CSCI1600: Embedded and Real Time SoftwareLecture 11: Modeling IV: Concurrency

Steven Reiss, Fall 2015

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 theorems (e.g. no deadlock)

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 of these

Utility of Petri Nets

Modeling and studying synchronization

Modeling and studying asynchronous behaviors

Modeling and studying resource sharing

Petri Net Usage Good fit for embedded systems

Model communciation in FSAs

Some more modern equivalents

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

Motivation

Transitions are as important as states 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

Petri Net Components Bipartite graph

Places

Labeled circles

Represent states

Transitions

Labeled bars

Represent transitions

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

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

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

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

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.

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

Pure : no self loops

No place is input and output of a single transition

Can always convert a Petri net into a pure one

Choosing transitions to fire

Nondeterministic, one at a time

Nondeterministic, set of non-conflicting transitions

Can add priorities

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 the the buffer

The other removes from it

Modeling producer consumer

Robots can also work outside the workspace

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

P1

P6

P5

P4

P9

P7

P8

P3

P2

B=3

P1

P6

P5

P4

P9

P7

P8

P3

P2

B=3

Example Dining Philosphers

Petri Nets Reachability

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)

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

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 stare reachable from M0, it is possible to fire any transition in the net Sufficient, not necessary (why)

Can quantify various degrees of liveness

Petri Net Properties

A Petri Net is reversable if for every marking M in R(M0), M0 is reachable from M

Error recovery

Could use a different state other them M0

Proving Properties

Petri nets are inherently finite

Construct a tree of all possible markings Flag states that are duplicates

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 tree is finite

Proving Properties

Given the finite coverability tree Proving properties is easy

Just check the property holds in each tree node

Can be done mechanically

Homework

Read 2.4