11Fall 2015, arz1 CPE555A: Real-Time Embedded Systems Lecture 10 Ali Zaringhalam Stevens Institute...

11Fall 2015, arz 1

CPE555A:Real-Time Embedded Systems

Lecture 10Ali Zaringhalam

Stevens Institute of Technology

Fall 2015, arz

CS555A – Real-Time Embedded SystemsStevens Institute of Technology 2


Outline

Deadlock Finite State Machines Non-deterministic FSM

Fall 2015, arz 3

The Deadlock Problem

A set of blocked processes each holding a resource and waiting to acquire a resource held by another process in the set

Example System has 2 separate resources (e.g., Devices A

and B) each protected by a separate mutex P1 and P2 each hold one mutex and each needs

the other one Example

Mutex A and B, initialized to 1

P0 P1

wait (A); wait(B)wait (B); wait(A)

P0 gets A and blocks on B.

P1 gets B and blocks on A.

CS555A – Real-Time Embedded SystemsStevens Institute of Technology

Fall 2015, arz 4


Bridge Crossing Example

Traffic only in one direction Each section of a bridge can be viewed as a resource If a deadlock occurs, it can be resolved if one car

backs up (preempt resources and rollback) Several cars may have to be backed up if a deadlock

occurs Starvation is possible Note – Most OS do not prevent or deal with deadlocks

How can we reason about deadlocks? We need models!

Fall 2015, arz 5

System Model

Resource types R1, R2, . . ., Rm

Example resource types: memory, I/O devices, files

Each resource type Ri has Wi instances.

Each process utilizes a resource as follows: Request Use Release


Fall 2015, arz 6

Deadlock Characterization

Mutual exclusion: only one process at a time can use a resource

Hold and wait: a process holding at least one resource is allowed to wait to acquire additional resources held by other processes

No resource preemption: a resource can be released only voluntarily by the process holding it, after that process has completed its task

Circular wait: there exists a set {P0, P1, …, P0} of waiting processes such that P0 is waiting for a resource that is held by P1, P1 is waiting for a resource that is held by P2,…, Pn–1 is waiting for a resource that is held by Pn, and Pn is waiting for a resource that is held by P0.

Deadlock can arise if four necessary conditions hold simultaneously. If any one of these conditions is not met, there cannot be a deadlock.


Fall 2015, arz 7

Resource-Allocation Graph

V is partitioned into two types: P = {P1, P2, …, Pn}, the set consisting of all

the active processes in the system R = {R1, R2, …, Rm}, the set consisting of all

resource types in the system Request edge – directed edge Pi Rj

Assignment edge – directed edge Rj Pi

A set of vertices V and a set of edges E.


Fall 2015, arz 8

Resource-Allocation Graph (Cont.)

Process

Resource Type with 4 instances

Request Edge: Pi requests instance of Rj

Assignment Edge: Pi is holding an instance of Rj

Pi

Pi

Rj

Rj


Fall 2015, arz 9

Example of a Resource Allocation Graph

Are {P1, P2} in deadlock? Does the system have deadlocks?

Deadlock: A set of blocked processes each holding a resource and waiting to acquire a resource held only by other processes in the set.


Fall 2015, arz 10

Resource Allocation Graph With A Deadlock

P1 cannot progress unless P2 can progress

P2 can’t progress unless P3 can progress

P3 can’t progress unless

P1 can progress OR P2 can progress

P1, P2 and P3 are deadlocked

What is the “set of processes” in deadlock?

Does the presence of a cycle in the graph imply a deadlock?

Two cycles• P1 -> R1 -> P2 -> R3 -> P3 -> R2 -> P1• P2 -> R3 -> P3 -> R2 -> P2


Fall 2015, arz 11

Graph With A Cycle But No Deadlock

Why is there no deadlock here?

Cycle: P1->R1->P3->R2->P1

P4 has no resource dependency

It can continue and finish It then releases the R2

resource This allows P3 to acquire

R2 breaking the cycle


Fall 2015, arz 12

Basic Facts

If graph contains no cycles no deadlock Cycle is a necessary condition

If graph contains a cycle If only one instance per resource type, then

deadlock In this case the presence of a cycle is sufficient for a

deadlock If several instances per resource type, there is

a possibility of deadlock In this case the presence of a cycle is NOT sufficient

for a deadlock


Fall 2015, arz 13

Methods for Handling Deadlocks

Ensure that the system will never enter a deadlock state.

Allow the system to enter a deadlock state, detect the situation, and then recover.

Ignore the problem and pretend that deadlocks never occur in the system; used by most operating systems, including LINUX Deadlock is viewed as a problem at

the application level


Fall 2015, arz 14

Deadlock Characterization

Mutual exclusion: only one process at a time can use a resource

Hold and wait: a process holding at least one resource can wait to acquire additional resources held by other processes

No resource preemption: a resource can be released only voluntarily by the process holding it, after that process has completed its task

Circular wait: there exists a set {P0, P1, …, P0} of waiting processes such that P0 is waiting for a resource that is held by P1, P1 is waiting for a resource that is held by P2,…, Pn–1 is waiting for a resource that is held by Pn, and Pn is waiting for a resource that is held by P0.

Deadlock can arise if four necessary conditions hold simultaneously. If any one of these conditions is not met, there cannot be a deadlock.


Fall 2015, arz 15

Deadlock Prevention

Mutual Exclusion – do not require mutual exclusion by always having resources that can be shared (e.g., read-only file)

In general, not practical because in concurrent programs we typically have resources that cannot be shared.

Hold and Wait (i.e., a process holding at least one resource can wait to acquire additional resources held by other processes)

Must guarantee that whenever a process requests a resource, it does not hold any other resources.

If multiple resources are required, the process must request and be allocated all its resources before it begins execution, or allow process to request resources only when the process has none.

Low resource utilization; starvation possible.

Idea: Ensure that at least one of the necessary conditions for deadlock does not occur. Constrain the ways in which requests can be made.


Fall 2015, arz 16

Example – Hold-&-Wait Protocols

A process needs to copy from a tape drive to a disk file, sort the file and then print it

Request all three resources at the beginning. A resource such as the printer will be under-utilized

Allow process to request resources only when the process has none

Process obtains tape drive and disk file first; copies from tape to disk; then releases both

Process obtains disk file and printer next But there is no guarantee that someone else did not

modify the disk file between the steps Starvation is also possible if there are

“popular” resources that are widely in demand


Fall 2015, arz 17

Deadlock Prevention (Cont.) No Preemption – (allow preemption of resources from

processes) If a process that is holding some resources requests another

resource that cannot be immediately allocated to it, then all resources currently being held by the process are taken away.

Preempted resources are added to the list of resources for which the process is waiting.

Process will be restarted only when it can regain its old resources, as well as any new ones that it is requesting.

Problem: state of the preempted process must be saved. This may not be practical.

Circular Wait – impose a total ordering of all resource types, and require that each process requests resources in an increasing order of enumeration.

It is up to applications to request resources in increasing order If application developers make a mistake, all bets are off


Fall 2015, arz 18

Resource Ordering Example

Suppose we have three resources Resource A with F(A)=1 Resource B with F(B)=5 Resource C with F(C)=12

Each process must request resources in increasing order of F A process can request A, then B then C A process cannot request B, then C then A

Why increasing?


Fall 2015, arz 19

Deadlock Avoidance

Simplest and most useful model requires that each process declare the maximum number of resources of each type that it may need.

The deadlock-avoidance algorithm dynamically examines the resource-allocation state to ensure that there can never be a circular-wait condition.

Resource-allocation state is defined by the number of available and allocated resources, and the maximum demands of the processes.

Requires that the system has some additional prior information available in advance about processes and their required resources.


Fall 2015, arz 20

Avoidance algorithms

Assume single instance of a resource type (maximum number of each resource type needed is 1)

Use resource-allocation graph. Basic idea: Resources can be granted

only if this does not create cycles in the resource-allocation graph. Why?

Requires checking for cycles in directed graphs: quadratic algorithm in the number of processes.


Fall 2015, arz 21

Resource-Allocation Graph Scheme

Claim edge Pi Rj indicates that process Pi may request resource Rj represented by a dashed line (known statically before run-time)

Claim edge converts to request edge when a process requests a resource

Request edge converted to an assignment edge when the resource is allocated to the process

When a resource is released by a process, assignment edge reconverts to a claim edge

Resources must be claimed a priori in the system before starting the concurrent program


Fall 2015, arz 22

Unsafe State In Resource-Allocation Graph

Initial State


Fall 2015, arz 23

Resource-Allocation Graph


Fall 2015, arz 24

Resource-Allocation Graph Algorithm

Suppose that process Pi requests a resource Rj

The request can be granted only if converting the request edge to an assignment edge does not result in the formation of a cycle in the resource allocation graph

How does the system make progress in this example?


Fall 2015, arz 25

Resource-Allocation Graph - Progress

Progress is made when P1 is ready to request R2. Assignment of R2 to P1 does not result in a cycle. There will not be a possibility of deadlock when P2 requests R2.

Initial State


Fall 2015, arz 26

Deadlock Detection

Allow system to enter deadlock state

Detection algorithm

Recovery scheme


Fall 2015, arz 27

Single Instance of Each Resource Type

Maintain wait-for graph Nodes are processes Pi Pj if Pi is waiting for Pj

Periodically invoke an algorithm that searches for a cycle in the graph. If there is a cycle, there exists a deadlock

An algorithm to detect a cycle in a graph requires an order of n2 operations, where n is the number of vertices in the graph


Fall 2015, arz 28

Resource-Allocation Graph and Wait-for Graph

Resource-Allocation Graph Corresponding wait-for graph


Fall 2015, arz 29

Detection-Algorithm Usage

When, and how often, to invoke depends on: How often a deadlock is likely to occur? How many processes will need to be rolled back?

one for each disjoint cycle

If detection algorithm is invoked arbitrarily, there may be many cycles in the resource graph and so we would not be able to tell which of the many deadlocked processes “caused” the deadlock


Fall 2015, arz 30

Recovery from Deadlock: Process Termination

Abort all deadlocked processes Abort one process at a time until the deadlock cycle is

eliminated In which order should we choose to abort?

Priority of the process How long process has computed, and how much longer to

completion Resources the process has used Resources process needs to complete How many processes will need to be terminated


Fall 2015, arz 31

Recovery from Deadlock: Resource Preemption

Selecting a victim – minimize cost Rollback – return to some safe

state, restart process for that state

Starvation – same process may always be picked as victim, include number of rollback in cost factor


Fall 2015, arz 32

Priority Ceiling Protocol

Task 2 starts first and acquires lock a, then gets preempted by the higher priority task 1.

Task 1 acquires lock b and then blocks trying to acquire lock a. Task 2 then blocks trying to acquire lock b, and no further

progress is possible. We have discussed this before. Now we want to see if we can

use priority to prevent this type of deadlock

Priority


Fall 2015, arz 33

Priority Ceiling Protocol - Continued

Every lock or semaphore is assigned a static priority ceiling (before run-time) equal to the priority of the highest-priority task that can lock it.

A task T can acquire a lock a only if the task’s priority is strictly higher than the priority ceilings of all locks currently held by other tasks. Intuitively, if we prevent task T from

acquiring lock a, then we ensure that task T will not hold lock a while later trying to acquire other locks held by other tasks.

This prevents deadlockCS555A – Real-Time Embedded Systems

Stevens Institute of Technology

Fall 2015, arz 34

Priority Ceiling

Locks a and b are assigned the priority of task 1 which is the highest priority task that can hold these locks. This is a ceiling on the priority of the tasks that can acquire the lock

A task can acquire a lock only if the task’s priority is higher than the priority of all locks currently held by other tasks

At time t=3, can task 1 acquire lock b? System checks priority(task_one) = P_High System checks the priority of all locks currently held by other tasks. It finds

lock a held by task 2. The priority ceiling of lock a is priority(lock_a) = P_High

Because priority(task_one) is NOT higher than priority(lock_a), it is not allowed to acquire lock b. It blocks on b even though no other task holds it.

Can a task with a higher priority than task 1 acquire lock b?

How can we implement this in practice?


Fall 2015, arz


Modeling

Developing insight about a complex system through imitation/simulation

A model simulates the behavior of the system under investigation/development

Models: Mathematical: a set of definitions and

mathematical formula Computer: simulate system behavior in

software

Fall 2015, arz


Modeling Systems

A system is characterized by its states The dynamic of a system consists of a

description of the evolution of system state as a function of time

Continuous systems have a continuum of states and transition smoothly through these as a function of time

A discrete system is characterized by A set of discrete states Discontinuous/abrupt transition between

these states as a function of time

Fall 2015, arz


Discrete System Example

Count the number of cars that enter and leave a parking garage in order to keep track of how many cars are in the garage at any time

up, down are pure signals Counter

Show the current count on the display when an event occurs Shows nothing on the display otherwise

ArrivalDetector and DepartureDetector are actors and represent sensors in our model. They detect arrival and departure of cars and produce events for the Counter actor which keeps a running count.

Fall 2015, arz


Pure Signal

up(t) and down(t) are both functions of time.

At any given time a pure function u(t) has one of two values u(t)=absent; there is no event u(t)=present; there is an event

The signal has no associated value (its amplitude is not important)

Fall 2015, arz


Counter Behavior & Reaction

When up(t)=present, the counter reacts: it increments the counter and shows the new value

When down(t)=present, the counter reacts: it decrements the counter and shows the new value

At other times when up(t)=down(t)=absent, there is no reaction: it does not show any output

Fall 2015, arz


State Space

A practical parking garage has a finite number of parking slots: M

The state space of the counter is States = {0, 1, 2,….., M} The number of states is finite

The state encodes a summary of its past The state also determines the reaction to

future events

Fall 2015, arz


Finite-State Machine

A state machine models systems with discrete dynamics At each reaction, map valuations of

input to valuations of output The mapping function depends on the

current state A finite-state machine (FSM) has a

finite set of states

Fall 2015, arz


Graphical Notation Each state is represented

by a bubble Transition is represented by

an arrow from one state to another

Guard is a boolean variable which determines whether the action will be taken on a reaction

True: transition taken False: transition not taken

Action determines what output is produced in a reaction when transition is taken

Self-transition

Fall 2015, arz


Reaction in Event-Triggered Model

Suppose a reaction occurs when input is present If the system is in state S1 and x=present, the

transition will be taken and the output is y=present This is an event-triggered model

Transitions occur when event X occurs in the environment. For example a control button is pressed.

S2S1

x/y

Input: x = {present, absent}Output: y = {present, absent}

Input

Fall 2015, arz


• Guard means if a car is entering (up=present) and no car is leaving (down=absent)• Action when enabled is to display output counter=3

Finite number of states.

AND operationNegation operation

Initial state.

Event-DrivenFSM For Garage Counter

Fall 2015, arz


When Does a Reaction Occur?

Suppose This is an event-triggered model X and y are pure signals

When does a reaction occur? When the environment triggers a reaction and the

input is absent What happens when there is no input? What happens when there is an input

S2S1

!x /y


Input

FSM only reacts when event X occurs. But the guard disables the transition when an event is present! So the system remains in s1.

Fall 2015, arz

Time-triggered Model

In a time-triggered model Clock input is gated with other inputs All inputs are discrete A reaction occurs on the tick of a clock and

gated by the input In this case there can be a transition on the

clock tick even if X is absent


S2S1

x/y


Input

S2S1

!x /y


Input

Fall 2015, arz


ExampleReference: Claudius Ptolemaeus, Editor: Introduction to Embedded Systems, http://ptolemy.eecs.berkeley.edu/index.htm

• High water-mark:22• Low water-mark: 18

Fall 2015, arz


Thermostat Model

Temperature increase per unit time as a result of heating.

Temperature decrease per unit time when heater is not on.

Model parameters

Output: heats or coolsthe environment.Input: ambient temperature

of environment.

Fall 2015, arz


Other Issues

How do you drive the thermostat model? Modeling input side

How do you test it? Viewing the response/output

Fall 2015, arz


Driver, Input & Output

Drives scheduling by generating a periodic timing signal. All model components react to the periodic signal

Models temperature behavior in the environment.

Displays temperature.

Displays heating/cooling response

Fall 2015, arz

Modeling Temperature Behavior


Fall 2015, arz

Default Transition

A default transition is enabled if No non-default transition is enabled There is either no guard or the guard

evaluates to true When is the default transition

enabled?CS555A – Real-Time Embedded SystemsStevens Institute of Technology 52

Alternatively we can define a ordinary transition with guard = ! ( up & !down) which is the complement of the (up & !down) transition.

• A default transition has a lower priority than an ordinary transition. It is like the default case in the switch/case statement in C.• If the guard in both an ordinary and the default transitions evaluate to TRUE, the ordinary transition wins and is taken.

Fall 2015, arz


Default is when T< heatOffThreshold

Default is when T> heatOnThreshold

Default Transition Example

Fall 2015, arz


Example: Formal Description

States: (0, 1) s(0) = cooling s(1)=heating

InitialState= 0 Input: temperature T Output:

heatOn -> { present, absent } heatOff -> {present, absent)

Update(s, T) Update(0, T) = (1, heatOn) if T<=18 Update(1, T) = ( 0, heatOff) if T>=22

Fall 2015, arz


Garage Counter Example

The notation here is a bit awkward because the parameter M may be large

Fall 2015, arz

Extended State Machine

Extended State machine augments the FSM model with variables that can be read or written

What is the size of the state space?

The count variable is incremented only AFTER guard has been evaluated and output generated

Fall 2015, arz


Number of States

For an Extended State Machine with n discrete states (bubbles) m variables each with p possible values Number of states = nxpm

In general an Extended State Machine may not be a Finite State machine Example:

A variable can be any real number

Fall 2015, arz

Notation for Extended FSM

Make explicit declarations of variables, inputs and outputs

•set action may alter variables of extended FSM•The actions on variables are taken only AFTER guard has been evaluated and output generated

Fall 2015, arz


FSM Structure - 1

FSM consists of a set of states and transitions One initial state Any number of final states (0-N) Guard expressions gating transitions Any number of output actions Any number of set actions for

extended variables

Fall 2015, arz


FSM Structure - 2

Firing phase operations Read inputs Evaluate guards on outgoing

transitions of the current state Choose a transition whose guard

evaluates to true Execute the output actions on the

chosen transition, if any

Fall 2015, arz


FSM Structure - 3

Post-fire operations Execute the set actions of the chosen

transition, which determines the values of extended variables

Change the current state to the destination of the chosen transition

Fall 2015, arz


Deterministic FSM

A state machine is said to be deterministic if, for each state, there is at most one transition enabled by each input value. The update function is a 1-1 mapping

Fall 2015, arz


Non-Deterministic FSM If for each state, more than one

transition is enabled by an input value, the FSM is said to be non-deterministic

The update function is 1-many mapping

In the heating state both red transitions fire on any input.

• The update function of a non-deterministic FSM has a 1-many mapping between (state, inputs) -> (state, output)• It is useful to think of it as a multi-valued function

11Fall 2015, arz1 CPE555A: Real-Time Embedded Systems Lecture 10 Ali Zaringhalam Stevens Institute...

Documents

Transcript of 11Fall 2015, arz1 CPE555A: Real-Time Embedded Systems Lecture 10 Ali Zaringhalam Stevens Institute...