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

2. Fall 2015, arz CS555A – Real-Time Embedded Systems Stevens Institute of Technology 2 CS555A – Real-Time Embedded Systems Stevens Institute of Technology 2 Outline Deadlock Finite State Machines Non-deterministic FSM

3. Fall 2015, arz3 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 P 1 and P 2 each hold one mutex and each needs the other one Example Mutex A and B, initialized to 1 P 0 P 1 wait (A);wait(B) wait (B);wait(A) P 0 gets A and blocks on B. P 1 gets B and blocks on A. CS555A – Real-Time Embedded Systems Stevens Institute of Technology

4. Fall 2015, arz4 CS555A – Real-Time Embedded Systems Stevens Institute of Technology 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!

5. Fall 2015, arz5 System Model Resource types R 1, R 2,..., R m Example resource types: memory, I/O devices, files Each resource type R i has W i instances. Each process utilizes a resource as follows: Request Use Release CS555A – Real-Time Embedded Systems Stevens Institute of Technology

6. Fall 2015, arz6 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 {P 0, P 1, …, P 0 } of waiting processes such that P 0 is waiting for a resource that is held by P 1, P 1 is waiting for a resource that is held by P 2,…, P n–1 is waiting for a resource that is held by P n, and P n is waiting for a resource that is held by P 0. Deadlock can arise if four necessary conditions hold simultaneously. If any one of these conditions is not met, there cannot be a deadlock. CS555A – Real-Time Embedded Systems Stevens Institute of Technology

7. Fall 2015, arz7 Resource-Allocation Graph V is partitioned into two types: P = {P 1, P 2, …, P n }, the set consisting of all the active processes in the system R = {R 1, R 2, …, R m }, the set consisting of all resource types in the system Request edge – directed edge P i  R j Assignment edge – directed edge R j  P i A set of vertices V and a set of edges E. CS555A – Real-Time Embedded Systems Stevens Institute of Technology

8. Fall 2015, arz8 Resource-Allocation Graph (Cont.) Process Resource Type with 4 instances Request Edge: P i requests instance of R j Assignment Edge: P i is holding an instance of R j PiPi PiPi RjRj RjRj CS555A – Real-Time Embedded Systems Stevens Institute of Technology

9. Fall 2015, arz9 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. CS555A – Real-Time Embedded Systems Stevens Institute of Technology

10. Fall 2015, arz10 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 CS555A – Real-Time Embedded Systems Stevens Institute of Technology

11. Fall 2015, arz11 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 CS555A – Real-Time Embedded Systems Stevens Institute of Technology

12. Fall 2015, arz12 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 CS555A – Real-Time Embedded Systems Stevens Institute of Technology

13. Fall 2015, arz13 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 CS555A – Real-Time Embedded Systems Stevens Institute of Technology

14. Fall 2015, arz14 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 {P 0, P 1, …, P 0 } of waiting processes such that P 0 is waiting for a resource that is held by P 1, P 1 is waiting for a resource that is held by P 2,…, P n–1 is waiting for a resource that is held by P n, and P n is waiting for a resource that is held by P 0. Deadlock can arise if four necessary conditions hold simultaneously. If any one of these conditions is not met, there cannot be a deadlock. CS555A – Real-Time Embedded Systems Stevens Institute of Technology

15. Fall 2015, arz15 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. CS555A – Real-Time Embedded Systems Stevens Institute of Technology

16. Fall 2015, arz16 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 CS555A – Real-Time Embedded Systems Stevens Institute of Technology

17. Fall 2015, arz17 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 CS555A – Real-Time Embedded Systems Stevens Institute of Technology

18. Fall 2015, arz18 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? CS555A – Real-Time Embedded Systems Stevens Institute of Technology

19. Fall 2015, arz19 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. CS555A – Real-Time Embedded Systems Stevens Institute of Technology

20. Fall 2015, arz20 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. CS555A – Real-Time Embedded Systems Stevens Institute of Technology

21. Fall 2015, arz21 Resource-Allocation Graph Scheme Claim edge P i  R j indicates that process P i may request resource R j 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 CS555A – Real-Time Embedded Systems Stevens Institute of Technology

22. Fall 2015, arz22 Unsafe State In Resource-Allocation Graph Initial State CS555A – Real-Time Embedded Systems Stevens Institute of Technology

23. Fall 2015, arz23 Resource-Allocation Graph CS555A – Real-Time Embedded Systems Stevens Institute of Technology

24. Fall 2015, arz24 Resource-Allocation Graph Algorithm Suppose that process P i requests a resource R j 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? CS555A – Real-Time Embedded Systems Stevens Institute of Technology

25. Fall 2015, arz25 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 CS555A – Real-Time Embedded Systems Stevens Institute of Technology

26. Fall 2015, arz26 Deadlock Detection Allow system to enter deadlock state Detection algorithm Recovery scheme CS555A – Real-Time Embedded Systems Stevens Institute of Technology

27. Fall 2015, arz27 Single Instance of Each Resource Type Maintain wait-for graph Nodes are processes P i  P j if P i is waiting for P j 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 n 2 operations, where n is the number of vertices in the graph CS555A – Real-Time Embedded Systems Stevens Institute of Technology

28. Fall 2015, arz28 Resource-Allocation Graph and Wait-for Graph Resource-Allocation GraphCorresponding wait-for graph CS555A – Real-Time Embedded Systems Stevens Institute of Technology

29. Fall 2015, arz29 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 CS555A – Real-Time Embedded Systems Stevens Institute of Technology

30. Fall 2015, arz30 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 CS555A – Real-Time Embedded Systems Stevens Institute of Technology

31. Fall 2015, arz31 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 CS555A – Real-Time Embedded Systems Stevens Institute of Technology

32. Fall 2015, arz32 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 CS555A – Real-Time Embedded Systems Stevens Institute of Technology

33. Fall 2015, arz33 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 deadlock CS555A – Real-Time Embedded Systems Stevens Institute of Technology

34. Fall 2015, arz34 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? CS555A – Real-Time Embedded Systems Stevens Institute of Technology

35. Fall 2015, arz CS555A – Real-Time Embedded Systems Stevens Institute of Technology 35 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

36. Fall 2015, arz CS555A – Real-Time Embedded Systems Stevens Institute of Technology 36 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

37. Fall 2015, arz CS555A – Real-Time Embedded Systems Stevens Institute of Technology 37 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.

38. Fall 2015, arz CS555A – Real-Time Embedded Systems Stevens Institute of Technology 38 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)

39. Fall 2015, arz CS555A – Real-Time Embedded Systems Stevens Institute of Technology 39 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

40. Fall 2015, arz CS555A – Real-Time Embedded Systems Stevens Institute of Technology 40 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

41. Fall 2015, arz CS555A – Real-Time Embedded Systems Stevens Institute of Technology 41 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

42. Fall 2015, arz CS555A – Real-Time Embedded Systems Stevens Institute of Technology 42 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

43. Fall 2015, arz CS555A – Real-Time Embedded Systems Stevens Institute of Technology 43 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. S2 S1 x/y Input: x = {present, absent} Output: y = {present, absent} Input

44. Fall 2015, arz CS555A – Real-Time Embedded Systems Stevens Institute of Technology 44 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 operation Negation operation Initial state. Event-Driven FSM For Garage Counter

45. Fall 2015, arz CS555A – Real-Time Embedded Systems Stevens Institute of Technology 45 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 S2 S1 !x /y Input: x = {present, absent} Output: y = {present, absent} 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.

46. 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 CS555A – Real-Time Embedded Systems Stevens Institute of Technology 46 S2 S1 x/y Input: x = {present, absent} Output: y = {present, absent} Input S2 S1 !x /y Input: x = {present, absent} Output: y = {present, absent} Input

47. Fall 2015, arz CS555A – Real-Time Embedded Systems Stevens Institute of Technology 47 Example Reference: Claudius Ptolemaeus, Editor: Introduction to Embedded Systems, http://ptolemy.eecs.berkeley.edu/index.htm High water-mark:22 Low water-mark: 18

48. Fall 2015, arz CS555A – Real-Time Embedded Systems Stevens Institute of Technology 48 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 cools the environment. Input: ambient temperature of environment.

49. Fall 2015, arz CS555A – Real-Time Embedded Systems Stevens Institute of Technology 49 Other Issues How do you drive the thermostat model? Modeling input side How do you test it? Viewing the response/output

50. Fall 2015, arz CS555A – Real-Time Embedded Systems Stevens Institute of Technology 50 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

51. Fall 2015, arz Modeling Temperature Behavior CS555A – Real-Time Embedded Systems Stevens Institute of Technology 51

52. 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 Systems Stevens 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.

53. Fall 2015, arz CS555A – Real-Time Embedded Systems Stevens Institute of Technology 53 Default is when T< heatOffThreshold Default is when T> heatOnThreshold Default Transition Example

54. Fall 2015, arz CS555A – Real-Time Embedded Systems Stevens Institute of Technology 54 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

55. Fall 2015, arz CS555A – Real-Time Embedded Systems Stevens Institute of Technology 55 Garage Counter Example The notation here is a bit awkward because the parameter M may be large

56. 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

57. Fall 2015, arz CS555A – Real-Time Embedded Systems Stevens Institute of Technology 57 Number of States For an Extended State Machine with n discrete states (bubbles) m variables each with p possible values Number of states = nxp m In general an Extended State Machine may not be a Finite State machine Example: A variable can be any real number

58. 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

59. Fall 2015, arz CS555A – Real-Time Embedded Systems Stevens Institute of Technology 59 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

60. Fall 2015, arz CS555A – Real-Time Embedded Systems Stevens Institute of Technology 60 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

61. Fall 2015, arz CS555A – Real-Time Embedded Systems Stevens Institute of Technology 61 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

62. Fall 2015, arz CS555A – Real-Time Embedded Systems Stevens Institute of Technology 62 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

63. Fall 2015, arz CS555A – Real-Time Embedded Systems Stevens Institute of Technology 63 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