Software for Embedded Systems

Models vs. Languages State Machine Model

Outline

State Machines and Concurrent Process Models

Adapted from: Embedded Systems Design: A Unified Hardware/Software Introduction, (c) 2000 Vahid/Givargis

FSM/FSMD HCFSM and Statecharts Language Program-State Machine (PSM) Model

Concurrent Process Model

Communication Synchronization Implementation

Dataflow Model Real-Time Systems

1 CSE466-02au Slide 2

Introduction
Describing embedded systems processing behavior
Can be extremely difficult
Complexity increasing with increasing IC capacity
Past: washing machines, small games, etc. Hundreds of lines of code Today: TV set-top boxes, Cell phone, etc. Hundreds of thousands of lines of code

An example of trying to be precise in English

California Vehicle Code
Right-of-way of crosswalks
21950. (a) The driver of a vehicle shall yield the right-of-way to a pedestrian crossing the roadway within any marked crosswalk or within any unmarked crosswalk at an intersection, except as otherwise provided in this chapter. (b) The provisions of this section shall not relieve a pedestrian from the duty of using due care for his or her safety. No pedestrian shall suddenly leave a curb or other place of safety and walk or run into the path of a vehicle which is so close as to constitute an immediate hazard. No pedestrian shall unnecessarily stop or delay traffic while in a marked or unmarked crosswalk. (c) The provisions of subdivision (b) shall not relieve a driver of a vehicle from the duty of exercising due care for the safety of any pedestrian within any marked crosswalk or within any unmarked crosswalk at an intersection.

Desired behavior often not fully understood in beginning

Many implementation bugs due to description mistakes/omissions

English (or other natural language) common starting point

Precise description difficult to impossible Example: Motor Vehicle Code thousands of pages long...

All that just for crossing the street (and theres much more)!

CSE466-02au

Slide 3

CSE466-02au

Slide 4

Models and languages

How can we (precisely) capture behavior?
We may think of languages (C, C++), but computation model is the key

Models vs. languages

Poetry Recipe Story

Models

State machine

Sequent. program

Dataflow

Common computation models:

Sequential program model
Statements, rules for composing statements, semantics for executing them

Languages

English

Spanish

Japanese

C++

Java

Recipes vs. English

Sequential programs vs. C

Communicating process model

Multiple sequential programs running concurrently

Slide 5

Computation models describe system behavior

Conceptual notion, e.g., recipe, sequential program

State machine model

For control dominated systems, monitors control inputs, sets control outputs

Languages capture models

Concrete form, e.g., English, C

Dataflow model
For data dominated systems, transforms input data streams into output streams

Variety of languages can capture one model

E.g., sequential program model ! C,C++, Java

Object-oriented model
For breaking complex software into simpler, well-defined pieces
CSE466-02au

One language can capture variety of models

E.g., C++ sequential program model, object-oriented model, state machine model

Certain languages better at capturing certain computation models

Slide 6

CSE466-02au

Text versus Graphics

Models versus languages not to be confused with text versus graphics
Text and graphics are just two types of languages
Text: letters, numbers Graphics: circles, arrows (plus some letters, numbers)

Introductory example: An elevator controller

Partial English description System interface
up down open floor req Request Resolver

Simple elevator controller

Request Resolver resolves various floor requests into single requested floor Unit Control moves elevator to this requested floor

Move the elevator either up or down to reach the requested floor. Once at the requested floor, open the door for at least 10 seconds, and keep it open until the requested floor changes. Ensure the door is never open while moving. Dont change directions unless there are no higher requests when moving up or no lower requests when moving down

Unit Control

...

b1 b2 bN up1 up2 dn2 up3 dn3

buttons inside elevator

X = 1; Y = X + 1;

X=1

up/down buttons on each floor

Y=X+1

Try capturing in C...

...
dnN

CSE466-02au

Slide 7

CSE466-02au

Slide 8

Elevator controller using a sequential program model

Sequential program model
Inputs: int floor; bit b1..bN; up1..upN-1; dn2..dnN; Outputs: bit up, down, open; Global variables: int req; void UnitControl() { up = down = 0; open = 1; while (1) { while (req == floor); open = 0; if (req > floor) { up = 1;} else {down = 1;} while (req != floor); up = down = 0; open = 1; delay(10); } } void RequestResolver() { while (1) ... req = ... ... } void main() { Call concurrently: UnitControl() and RequestResolver() }

Finite-state machine (FSM) model

Trying to capture this behavior as sequential program is a bit awkward Instead, we might consider an FSM model, describing the system as:
Possible states
buttons inside elevator

System interface Partial English description Move the elevator either up or down to reach the requested floor. Once at the requested floor, open the door for at least 10 seconds, and keep it open until the requested floor changes. Ensure the door is never open while moving. Dont change directions unless there are no higher requests when moving up or no lower requests when moving down
Unit Control up down open floor req Request Resolver

...

b1 b2 bN up1 up2 dn2 up3 dn3

E.g., Idle, GoingUp, GoingDn, DoorOpen

Possible transitions from one state to another based on input

E.g., req > floor

up/down buttons on each floor

Actions that occur in each state

E.g., In the GoingUp state, u,d,o,t = 1,0,0,0 (up = 1, down, open, and timer_start = 0)

You might have come up with something having even more if statements.

...
dnN

Try it...
CSE466-02au

CSE466-02au

Slide 9

Slide 10

Finite-state machine (FSM) model

UnitControl process using a state machine
req > floor

Formal definition
An FSM is a 6-tuple F<S, I, O, F, H, s0>
S is a set of all states {s0, s1, , sl} I is a set of inputs {i0, i1, , im} O is a set of outputs {o0, o1, , on} F is a next-state function (S x I S) H is an output function (S O) s0 is an initial state

u,d,o, t = 1,0,0,0

GoingUp req > floor

!(req > floor) timer < 10 !(timer < 10)

u,d,o,t = 0,0,1,0 Idle req == floor req < floor

DoorOpen u,d,o,t = 0,0,1,1 !(req<floor) u is up, d is down, o is open

Moore-type
Associates outputs with states (as given above, H maps S O)

Mealy-type
Associates outputs with transitions (H maps S x I O)

u,d,o,t = 0,1,0,0

GoingDn

Shorthand notations to simplify descriptions

Implicitly assign 0 to all unassigned outputs in a state Implicitly AND every transition condition with clock edge (FSM is synchronous)
Slide 11 CSE466-02au Slide 12

req < floor

t is timer_start

CSE466-02au

Finite-state machine with datapath model (FSMD)

FSMD extends FSM: complex data types and variables for storing data
FSMs use only Boolean data types and operations, no variables

Describing a system as a state machine

1. List all possible states 2. Declare all variables (none in this example) 3. For each state, list possible transitions, with conditions, to other states 4. For each state and/or transition, list associated actions 5. For each state, ensure exclusive and complete exiting transition conditions
No two exiting conditions can be true at same time
Otherwise nondeterministic state machine
req > floor

FSMD: 7-tuple <S, I , O, V, F, H, s0>

S is a set of states {s0, s1, , sl} I is a set of inputs {i0, i1, , im} O is a set of outputs {o0, o1, , on}
u,d,o, t = 1,0,0,0

We described UnitControl as an FSMD

req > floor GoingUp !(req > floor) timer < 10 DoorOpen u,d,o,t = 0,0,1,1

V is a set of variables {v0, v1, , vn}

F is a next-state function (S x I x V S) H is an action function (S O + V) s0 is an initial state

req > floor !(timer < 10) u,d,o,t = 0,0,1,0 Idle req == floor req < floor u,d,o,t = 0,1,0,0 GoingDn req < floor

u,d,o, t = 1,0,0,0

GoingUp req > floor

!(req > floor) timer < 10

!(req<floor) u is up, d is down, o is open t is timer_start

u,d,o,t = 0,0,1,0 Idle req == floor

!(timer < 10)

DoorOpen u,d,o,t = 0,0,1,1

req < floor !(req<floor) GoingDn

I,O,V may represent complex data types (i.e., integers, floating point, etc.) F,H may include arithmetic operations H is an action function, not just an output function
Describes variable updates as well as outputs

u,d,o,t = 0,1,0,0

One condition must be true at any given time

Reducing explicit transitions should be avoided when first learning

u is up, d is down, o is open req < floor t is timer_start

Complete system state now consists of current state, si, and values of all variables
Slide 13 CSE466-02au

CSE466-02au

Slide 14

State machine vs. sequential program model

Different thought process used with each model State machine:
Encourages designer to think of all possible states and transitions among states based on all possible input conditions

Try Capturing Other Behaviors with an FSM

E.g., Answering machine blinking light when there are messages E.g., A simple telephone answering machine that answers after 4 rings when activated E.g., A simple crosswalk traffic control light Others

Sequential program model:

Designed to transform data through series of instructions that may be iterated and conditionally executed

State machine description excels in many cases

More natural means of computing in those cases Not due to graphical representation (state diagram)
Would still have same benefits if textual language used (i.e., state table) Besides, sequential program model could use graphical representation (i.e., flowchart)

CSE466-02au

Slide 15

CSE466-02au

Slide 16

Capturing state machines in sequential programming language

Despite benefits of state machine model, most popular development tools use sequential programming language
C, C++, Java, Ada, VHDL, Verilog, etc. Development tools are complex and expensive, therefore not easy to adapt or replace
Must protect investment

Language subset approach

Follow rules (template) for capturing state machine constructs in equivalent sequential language constructs Used with software (e.g.,C) and hardware languages (e.g.,VHDL) Capturing UnitControl state machine in C
Enumerate all states (#define) Declare state variable initialized to initial state (IDLE) Single switch statement branches to current states case Each case has actions
up, down, open, timer_start
#define IDLE0 #define GOINGUP1 #define GOINGDN2 #define DOOROPEN3 void UnitControl() { int state = IDLE; while (1) { switch (state) { IDLE: up=0; down=0; open=1; timer_start=0; if (req==floor) {state = IDLE;} if (req > floor) {state = GOINGUP;} if (req < floor) {state = GOINGDN;} break; GOINGUP: up=1; down=0; open=0; timer_start=0; if (req > floor) {state = GOINGUP;} if (!(req>floor)) {state = DOOROPEN;} break; GOINGDN: up=1; down=0; open=0; timer_start=0; if (req < floor) {state = GOINGDN;} if (!(req<floor)) {state = DOOROPEN;} break; DOOROPEN: up=0; down=0; open=1; timer_start=1; if (timer < 10) {state = DOOROPEN;} if (!(timer<10)){state = IDLE;} break; } } }

Two approaches to capturing state machine model with sequential programming language
Front-end tool approach
Additional tool installed to support state machine language
Graphical and/or textual state machine languages May support graphical simulation Automatically generate code in sequential programming language that is input to main development tool

Drawback: must support additional tool (licensing costs, upgrades, training, etc.)

Language subset approach

Most common approach...

Each case checks transition conditions to determine next state

if() {state = ;}

UnitControl state machine in sequential programming language

CSE466-02au

Slide 17

CSE466-02au

Slide 18

General template
#define S0 0 #define S1 1 ... #define SN N void StateMachine() { int state = S0; // or whatever is the initial state. while (1) { switch (state) { S0: // Insert S0s actions here & Insert transitions Ti leaving S0: if( T0s condition is true ) {state = T0s next state; /*actions*/ } if( T1s condition is true ) {state = T1s next state; /*actions*/ } ... if( Tms condition is true ) {state = Tms next state; /*actions*/ } break; S1: // Insert S1s actions here // Insert transitions Ti leaving S1 break; ... SN: // Insert SNs actions here // Insert transitions Ti leaving SN break; } } }

HCFSM and the Statecharts language

Hierarchical/concurrent state machine model (HCFSM)
Extension to state machine model to support hierarchy and concurrency States can be decomposed into another state machine
With hierarchy has identical functionality as Without hierarchy, but has one less transition (z) Known as OR-decomposition Known as AND-decomposition Without hierarchy
A1 x A2

With hierarchy
A A1

z y w
z B x

z
y

A2

States can execute concurrently

Concurrency
B C C1 x C2 y u D2 D D1 v

Statecharts
Graphical language to capture HCFSM timeout: transition with time limit as condition history: remember last substate OR-decomposed state A was in before transitioning to another state B
Return to saved substate of A when returning from B instead of initial state

CSE466-02au

Slide 19

CSE466-02au

Slide 20

UnitControl with FireMode

req>floor u,d,o = 1,0,0 u,d,o = 0,0,1 req==floor u,d,o = 0,1,0 GoingUp req>floor Idle req<floor GoingDn req<floor !(req>floor) timeout(10) !(req<floor) fire fire fire DoorOpen fire FireGoingDn floor>1 !fire u,d,o = 0,0,1 UnitControl

Program-state machine model (PSM): HCFSM plus sequential program model

Program-states actions can be FSM or sequential program
Designer can choose most appropriate
ElevatorController int req; UnitControl NormalMode up = down = 0; open = 1; while (1) { while (req == floor); open = 0; if (req > floor) { up = 1;} else {down = 1;} while (req != floor); open = 1; delay(10); } } !fire fire FireMode up = 0; down = 1; open = 0; while (floor > 1); up = 0; down = 0; open = 1; RequestResolver ... req = ... ...

FireMode
When fire is true, move elevator to 1st floor and open door w/o hierarchy: Getting messy! w/ hierarchy: Simple!
With hierarchy
UnitControl

u,d,o = 0,1,0 floor==1 u,d,o = 0,0,1 FireDrOpen fire

Stricter hierarchy than HCFSM used in Statecharts

transition between sibling states only, single entry Program-state may complete
Reaches end of sequential program code, OR FSM transition to special complete substate PSM has 2 types of transitions

Without hierarchy
req>floor u,d,o = 1,0,0 ElevatorController UnitControl NormalMode ... !fire FireMode !fire fire RequestResolver u,d,o = 0,0,1 req==floor u,d,o = 0,1,0 GoingUp req>floor Idle req<floor GoingDn req<floor

NormalMode

!(req>floor) timeout(10) !(req>floor) DoorOpen u,d,o = 0,0,1

Transition-immediately (TI): taken regardless of source program-state Transition-on-completion (TOC): taken only if condition is true AND source program-state is complete

fire

With concurrent RequestResolver CSE466-02au

FireMode u,d,o = 0,1,0 FireGoingDn floor==1 u,d,o = 0,0,1 floor>1 FireDrOpen fire

SpecCharts: extension of VHDL to capture PSM model SpecC: extension of C to capture PSM model
CSE466-02au

NormalMode and FireMode described as sequential programs Black square originating within FireMode indicates !fire is a TOC transition
Transition from FireMode to NormalMode only after FireMode completed

Slide 21

Slide 22

Role of appropriate model and language

Finding appropriate model to capture embedded system is an important step
Model shapes the way we think of the system
Originally thought of sequence of actions, wrote sequential program
First wait for requested floor to differ from target floor Then, we close the door Then, we move up or down to the desired floor Then, we open the door Then, we repeat this sequence

Concurrent process model

ConcurrentProcessExample() { x = ReadX() y = ReadY() Call concurrently: PrintHelloWorld(x) and PrintHowAreYou(y) } PrintHelloWorld(x) { while( 1 ) { print "Hello world." delay(x); } } PrintHowAreYou(x) { while( 1 ) { print "How are you?" delay(y); } }

Describes functionality of system in terms of two or more concurrently executing subtasks Many systems easier to describe with concurrent process model because inherently multitasking E.g., simple example:
Read two numbers X and Y Display Hello world. every X seconds Display How are you? every Y seconds

To create state machine, we thought in terms of states and transitions among states
When system must react to changing inputs, state machine might be best model HCFSM described FireMode easily, clearly

Language should capture model easily

Ideally should have features that directly capture constructs of model FireMode would be very complex in sequential program
Checks inserted throughout code

More effort would be required with sequential program or state machine model
Enter X: 1 Enter Y: 2 Hello world. Hello world. How are you? Hello world. How are you? Hello world. ...

PrintHelloWorld

Simple concurrent process example

ReadX

ReadY PrintHowAreYou time

Other factors may force choice of different model

Structured techniques can be used instead E.g., Template for state machine capture in sequential program language

(Time (Time (Time (Time (Time (Time

= = = = = =

1 2 2 3 4 4

s) s) s) s) s) s)

Subroutine execution over time

Sample input and output

CSE466-02au

Slide 23

CSE466-02au

Slide 24

Dataflow model
Derivative of concurrent process model Nodes represent transformations
May execute concurrently May or may not have token at any given time
Z = (A + B) * (C - D)

Synchronous dataflow
With digital signal-processors (DSPs), data flows at fixed rate Multiple tokens consumed and produced per firing Synchronous dataflow model takes advantage of this
Each edge labeled with number of tokens consumed/produced each firing Can statically schedule nodes, so can easily use sequential program model
Dont need real-time operating system and its overhead

A +

B C t1 t2 *

Edges represent flow of tokens (data) from one node to another When all of nodes input edges have at least one token, node may fire When node fires, it consumes input tokens processes transformation and generates output token Nodes may fire simultaneously Several commercial tools support graphical languages for capture of dataflow model
Can automatically translate to concurrent process model for implementation Each node becomes a process

A mA modulate mt1 tt1

B mB

C mC

D mD convolve

t1

t2 tt2

ct2

Nodes with arithmetic transformations

A modulate t1 t2 transform B C convolve D

How would you map this model to a sequential programming language? Try it... Algorithms developed for scheduling nodes into singleappearance schedules
Only one statement needed to call each nodes associated procedure
Allows procedure inlining without code explosion, thus reducing overhead even more

transform tZ Z

Synchronous dataflow

Nodes with more complex transformations

CSE466-02au

Slide 25

CSE466-02au

Slide 26

Concurrent processes
Consider two examples having separate tasks running independently but sharing data Difficult to write system using sequential program model Concurrent process model easier
Separate sequential programs (processes) for each task Programs communicate with each other
CSE466-02au Slide 27 CSE466-02au
Heartbeat Monitoring System
B[1..4]
Task 1: Read pulse If pulse < Lo then Activate Siren If pulse > Hi then Activate Siren Sleep 1 second Repeat Task 2: If B1/B2 pressed then Lo = Lo +/ 1 If B3/B4 pressed then Hi = Hi +/ 1 Sleep 500 ms Repeat

Heart-beat pulse

Concurrent processes and real-time systems

Set-top Box
Task 1: Read Signal Separate Audio/Video Send Audio to Task 2 Send Video to Task 3 Repeat Task 2: Wait on Task 1 Decode/output Audio Repeat Task 3: Wait on Task 1 Decode/output Video Repeat

Video Audio

Input Signal

Slide 28

Process
A sequential program, typically an infinite loop
Executes concurrently with other processes We are about to enter the world of concurrent programming

Communication among processes

Processes need to communicate data and signals to solve their computation problem
Processes that dont communicate are just independent programs solving separate problems
Encoded video packets
processA() { // Decode packet // Communicate packet to B } }

Basic operations on processes

Create and terminate
Create is like a procedure call but caller doesnt wait
Created process can itself create new processes

Basic example: producer/consumer

Process A produces data items, Process B consumes them E.g., A decodes video packets, B display decoded packets on a screen

Decoded video packets

void processB() { // Get packet from A // Display packet }

Terminate kills a process, destroying all data

Suspend and resume

Suspend puts a process on hold, saving state for later execution Resume starts the process again where it left off

How do we achieve this communication?

Two basic methods
Shared memory Message passing
Slide 29 CSE466-02au
To display

Join
A process suspends until a particular child process finishes execution
CSE466-02au

Slide 30

Shared Memory
Processes read and write shared variables
No time overhead, easy to implement But, hard to use mistakes are common
Example: Producer/consumer with a mistake
Share buffer[N], count
count = # of valid data items in buffer If buffer is full, must wait If buffer is empty, must wait
01: 02: 03: 04: 05: 06: 07: 08: 09: 10: 11: 12: 13: 14: 15: 16: 17: 18: 19: 20: 21: 22: 23: 24: 25: 26: data_type buffer[N]; int count = 0; void processA() { int i; while( 1 ) { produce(&data); while( count == N );/*loop*/ buffer[i] = data; i = (i + 1) % N; count = count + 1; } } void processB() { int i; while( 1 ) { while( count == 0 );/*loop*/ data = buffer[i]; i = (i + 1) % N; count = count - 1; consume(&data); } } void main() { create_process(processA); create_process(processB); }

Message Passing
Message passing
Data explicitly sent from one process to another
Sending process performs special operation, send Receiving process must perform special operation, receive, to receive the data Both operations must explicitly specify which process it is sending to or receiving from Receive is blocking, send may or may not be blocking
void processA() { while( 1 ) { produce(&data) send(B, &data); /* region 1 */ receive(B, &data); consume(&data); } } void processB() { while( 1 ) { receive(A, &data); transform(&data) send(A, &data); /* region 2 */ } }

processA produces data items and stores in buffer processB consumes data items from buffer Error when both processes try to update count concurrently (lines 10 and 19) and the following execution sequence occurs. Say count is 3.
A loads count (count = 3) from memory into register R1 (R1 = 3) A increments R1 (R1 = 4) B loads count (count = 3) from memory into register R2 (R2 = 3) B decrements R2 (R2 = 2) A stores R1 back to count in memory (count = 4) B stores R2 back to count in memory (count = 2)

Safer model, but less flexible

count now has incorrect value of 2

CSE466-02au

Slide 31

CSE466-02au

Slide 32

Back to Shared Memory: Mutual Exclusion

Certain sections of code should not be performed concurrently
Critical section
Possibly noncontiguous section of code where simultaneous updates, by multiple processes to a shared memory location, can occur

Correct Shared Memory Solution to the Consumer-Producer Problem

The primitive mutex is used to ensure critical sections are executed in mutual exclusion of each other Following the same execution sequence as before:
A/B execute lock operation on count_mutex Either A or B will acquire lock
Say B acquires it A will be put in blocked state
01: 02: 03: 04: 05: 06: 07: 08: 09: 10: 11: 12: 13: 14: 15: 16: 17: 18: 19: 20: 21: 22: 23: 24: 25: 26: 27: 28: 29: 30: 31: data_type buffer[N]; int count = 0; mutex count_mutex; void processA() { int i; while( 1 ) { produce(&data); while( count == N );/*loop*/ buffer[i] = data; i = (i + 1) % N; count_mutex.lock(); count = count + 1; count_mutex.unlock(); } } void processB() { int i; while( 1 ) { while( count == 0 );/*loop*/ data = buffer[i]; i = (i + 1) % N; count_mutex.lock(); count = count - 1; count_mutex.unlock(); consume(&data); } } void main() { create_process(processA); create_process(processB); }

When a process enters the critical section, all other processes must be locked out until it leaves the critical section
Mutex
A shared object used for locking and unlocking segment of shared data Disallows read/write access to memory it guards Multiple processes can perform lock operation simultaneously, but only one process will acquire lock All other processes trying to obtain lock will be put in blocked state until unlock operation performed by acquiring process when it exits critical section These processes will then be placed in runnable state and will compete for lock again

B loads count (count = 3) from memory into register R2 (R2 = 3) B decrements R2 (R2 = 2) B stores R2 back to count in memory (count = 2) B executes unlock operation
A is placed in runnable state again

A loads count (count = 2) from memory into register R1 (R1 = 2) A increments R1 (R1 = 3) A stores R1 back to count in memory (count = 3)

Count now has correct value of 3

CSE466-02au

Slide 33

CSE466-02au

Slide 34

Process Communication
Try modeling req value of our elevator controller
Using shared memory Using shared memory and mutexes Using message passing
System interface
up down open floor req Request Resolver

A Common Problem in Concurrent Programming: Deadlock

Deadlock: A condition where 2 or more processes are blocked waiting for the other to unlock critical sections of code
Both processes are then in blocked state Cannot execute unlock operation so will wait forever
01: 02: 03: 04: 05: 06: 07: 08: 09: 10: 11: 12: 13: 14: 15: 16: 17: 18: 19: 20: 21: 22: 23: 24: 25: mutex mutex1, mutex2; void processA() { while( 1 ) { mutex1.lock(); /* critical section mutex2.lock(); /* critical section mutex2.unlock(); /* critical section mutex1.unlock(); } } void processB() { while( 1 ) { mutex2.lock(); /* critical section mutex1.lock(); /* critical section mutex1.unlock(); /* critical section mutex2.unlock(); } } Unit Control

Example code has 2 different critical sections of code that can be accessed simultaneously
2 locks needed (mutex1, mutex2) Following execution sequence produces deadlock
A executes lock operation on mutex1 (and acquires it) B executes lock operation on mutex2( and acquires it) A/B both execute in critical sections 1 and 2, respectively A executes lock operation on mutex2
A blocked until B unlocks mutex2 B blocked until A unlocks mutex1

1 */ 2 */ 1 */

...

b1 b2 bN up1 up2 dn2 up3 dn3

buttons inside elevator

up/down buttons on each floor

2 */ 1 */ 2 */

B executes lock operation on mutex1 DEADLOCK!

...
dnN

One deadlock elimination protocol requires locking of numbered mutexes in increasing order and two-phase locking (2PL)
Acquire locks in 1st phase only, release locks in 2nd phase

CSE466-02au

Slide 35

CSE466-02au

Slide 36

Synchronization among processes

Sometimes concurrently running processes must synchronize their execution
When a process must wait for:
another process to compute some value reach a known point in their execution signal some condition

Condition variables
Condition variable is an object that has 2 operations, signal and wait When process performs a wait on a condition variable, the process is blocked until another process performs a signal on the same condition variable How is this done?
Process A acquires lock on a mutex Process A performs wait, passing this mutex
Causes mutex to be unlocked

Recall producer-consumer problem

processA must wait if buffer is full processB must wait if buffer is empty This is called busy-waiting
Process executing loops instead of being blocked CPU time wasted

Process B can now acquire lock on same mutex Process B enters critical section
Computes some value and/or make condition true

More efficient methods

Join operation, and blocking send and receive discussed earlier
Both block the process so it doesnt waste CPU time

Process B performs signal when condition true

Causes process A to implicitly reacquire mutex lock Process A becomes runnable

Condition variables and monitors

CSE466-02au Slide 37 CSE466-02au

Slide 38

Condition variable example: consumer-producer

2 condition variables
buffer_empty Signals at least 1 free location available in buffer buffer_full Signals at least 1 valid data item in buffer produces data item acquires lock (cs_mutex) for critical section checks value of count if count = N, buffer is full performs wait operation on buffer_empty this releases the lock on cs_mutex allowing processB to enter critical section, consume data item and free location in buffer processB then performs signal if count < N, buffer is not full processA inserts data into buffer increments count signals processB making it runnable if it has performed a wait operation on buffer_full
01: 02: 03: 04: 06: 07: 08: 09: 10: 11: 13: 14: 15: 16: 17: 18: 19: 20: 21: 22: 23: 24: 26: 27: 28: 29: 30: 31: 32: 33: 34: 35: 37:

Monitors
Collection of data and methods or subroutines that operate on data similar to an object-oriented paradigm Monitor guarantees only 1 process can execute inside monitor at a time (a) Process X executes while Process Y has to wait (b) Process X performs wait on a condition Process Y allowed to enter and execute (c) Process Y signals condition Process X waiting on Process Y blocked Process X allowed to continue executing (d) Process X finishes executing in monitor or waits on a condition again Process Y made runnable again
Process X (a) Monitor Process Y Process X (b) Monitor Waiting DATA CODE Process Y Monitor DATA CODE Waiting Monitor DATA CODE

Consumer-producer using condition variables

data_type buffer[N]; int count = 0; mutex cs_mutex; condition buffer_empty, buffer_full; void processA() { int i; while( 1 ) { produce(&data); cs_mutex.lock(); if( count == N ) buffer_empty.wait(cs_mutex); buffer[i] = data; i = (i + 1) % N; count = count + 1; cs_mutex.unlock(); buffer_full.signal(); } } void processB() { int i; while( 1 ) { cs_mutex.lock(); if( count == 0 ) buffer_full.wait(cs_mutex); data = buffer[i]; i = (i + 1) % N; count = count - 1; cs_mutex.unlock(); buffer_empty.signal(); consume(&data); } } void main() { create_process(processA); create_process(processB); }

processA:

DATA CODE

Process X (c)

Process Y

Process X (d)

Process Y

CSE466-02au

Slide 39

CSE466-02au

Slide 40

Monitor example: consumer-producer

Single monitor encapsulates both processes along with buffer and count One process will be allowed to begin executing first If processB allowed to execute first
Will execute until it finds count = 0 Will perform wait on buffer_full condition variable processA now allowed to enter monitor and execute processA produces data item finds count < N so writes to buffer and increments count processA performs signal on buffer_full condition variable processA blocked processB reenters monitor and continues execution, consumes data, etc.
01: 02: 03: 04: 06: 07: 08: 09: 10: 12: 13: 14: 15: 16: 17: 18: 19: 20: 21: 23: 24: 25: 26: 27: 28: 29: 30: 31: 32: 33: 35: Monitor { data_type buffer[N]; int count = 0; condition buffer_full, condition buffer_empty; void processA() { int i; while( 1 ) { produce(&data); if( count == N ) buffer_empty.wait(); buffer[i] = data; i = (i + 1) % N; count = count + 1; buffer_full.signal(); } } void processB() { int i; while( 1 ) { if( count == 0 ) buffer_full.wait(); data = buffer[i]; i = (i + 1) % N; count = count - 1; buffer_empty.signal(); consume(&data); buffer_full.signal(); } } } /* end monitor */ void main() { create_process(processA); create_process(processB); }

Implementation
Mapping of systems functionality onto hardware processors:
captured using computational model(s) written in some language(s)
State machine Sequent. program Dataflow Concurrent processes

The choice of computational model(s) is based on whether it allows the designer to describe the system.

Implementation choice independent from language(s) choice Implementation choice based on power, size, performance, timing and cost requirements Final implementation tested for feasibility
Also serves as blueprint/prototype for mass manufacturing of final product

Pascal

C/C++

Java

VHDL

The choice of language(s) is based on whether it captures the computational model(s) used by the designer. The choice of implementation is based on whether it meets power, size, performance and cost requirements.

Implementation A

Implementation B

Implementation C

CSE466-02au

Slide 41

CSE466-02au

Slide 42

Concurrent process model: implementation

True multitasking (parallel processing) General-purpose processors
Use programming language like C and compile to instructions of processor Expensive and in most cases not necessary
Process1 Process2 (b) Process3 Process4 General Purpose Processor Process1 Process2 (a) Process3 Process4 Processor B Processor C Processor D Communication Bus

Implementation: multiple processes sharing single processor

Processor A

Can use single and/or general-purpose processors (a) Multiple processors, each executing one process

Can manually rewrite processes as a single sequential program

Ok for simple examples, but extremely difficult for complex examples Automated techniques have evolved but not common E.g., simple Hello World concurrent program from before would look like:
I = 1; T = 0; while (1) { Delay(I); T = T + 1; if X modulo T is 0 then call PrintHelloWorld if Y modulo T is 0 then call PrintHowAreYou }

Custom single-purpose processors

More common

(b) One general-purpose processor running all processes

Most processes dont use 100% of processor time Can share processor time and still achieve necessary execution rates

Can use multitasking operating system

Much more common Operating system schedules processes, allocates storage, and interfaces to peripherals, etc. Real-time operating system (RTOS) can guarantee execution rate constraints are met Describe concurrent processes with languages having built-in processes (Java, Ada, etc.) or a sequential programming language with library support for concurrent processes (C, C++, etc. using POSIX threads for example) Less overhead (no operating system) More complex/harder to maintain Slide 44

Process1 Process2 (c) Process3 Process4 General Purpose Processor

(c) Combination of (a) and (b)

Multiple processes run on one general-purpose processor while one or more processes run on own single_purpose processor

Communication Bus

Processor A

Can convert processes to sequential program with process scheduling right in code

CSE466-02au

Slide 43

CSE466-02au

Processes vs. threads

Different meanings when operating system terminology Regular processes
Heavyweight process Own virtual address space (stack, data, code) System resources (e.g., open files)

Implementation: suspending, resuming, and joining

Multiple processes mapped to single-purpose processors
Built into processors implementation Could be extra input signal that is asserted when process suspended Additional logic needed for determining process completion
Extra output signals indicating process done

Threads
Lightweight process Subprocess within process Only program counter, stack, and registers Shares address space, system resources with other threads
Allows quicker communication between threads

Multiple processes mapped to single general-purpose processor

Built into programming language or special multitasking library like POSIX Language or library may rely on operating system to handle

Small compared to heavyweight processes

Can be created quickly Low cost switching between threads

CSE466-02au

Slide 45

CSE466-02au

Slide 46

Implementation: process scheduling

Must meet timing requirements when multiple concurrent processes implemented on single general-purpose processor
Not true multitasking

Scheduling: priority
Process with highest priority always selected first by scheduler
Typically determined statically during creation and dynamically during execution

Scheduler
Special process that decides when and for how long each process is executed Implemented as preemptive or nonpreemptive scheduler Preemptive
Determines how long a process executes before preempting to allow another process to execute
Time quantum: predetermined amount of execution time preemptive scheduler allows each process (may be 10 to 100s of milliseconds long)

FIFO
Runnable processes added to end of FIFO as created or become runnable Front process removed from FIFO when time quantum of current process is up or process is blocked

Priority queue
Runnable processes again added as created or become runnable Process with highest priority chosen when new process needed If multiple processes with same highest priority value then selects from them using first-come first-served Called priority scheduling when nonpreemptive Called round-robin when preemptive

Determines which process will be next to run

Nonpreemptive
Only determines which process is next after current process finishes execution
CSE466-02au

Slide 47

CSE466-02au

Slide 48

Priority assignment
Period of process
Repeating time interval the process must complete one execution within
E.g., period = 100 ms Process must execute once every 100 ms E.g., refresh rate of display is 27 times/sec Period = 37 ms

Real-time systems
Systems composed of 2 or more cooperating, concurrent processes with stringent execution time constraints
Rate monotonic
Process A B C D E F Period 25 ms 50 ms 12 ms 100 ms 40 ms 75 ms Priority 5 3 6 1 4 2

Usually determined by the description of the system

Execution deadline
Amount of time process must be completed by after it has started
E.g., execution time = 5 ms, deadline = 20 ms, period = 100 ms Process must complete execution within 20 ms after it has begun regardless of its period Process begins at start of period, runs for 4 ms then is preempted Process suspended for 14 ms, then runs for the remaining 1 ms Completed within 4 + 14 + 1 = 19 ms which meets deadline of 20 ms Without deadline process could be suspended for much longer

E.g., set-top boxes have separate processes that read or decode video and/or sound concurrently and must decode 20 frames/sec for output to appear continuous Other examples with stringent time constraints are:
digital cell phones navigation and process control systems assembly line monitoring systems multimedia and networking systems etc.

Deadline monotonic
Process G H I J K L Deadline 17 ms 50 ms 32 ms 10 ms 140 ms 32 ms Priority 5 2 3 6 1 4

Rate monotonic scheduling

Processes with shorter periods have higher priority Typically used when execution deadline = period Processes with shorter deadlines have higher priority Typically used when execution deadline < period

Deadline monotonic scheduling

Communication and synchronization between processes for these systems is critical Therefore, concurrent process model best suited for describing these systems
CSE466-02au Slide 50

CSE466-02au

Slide 49

Real-time operating systems (RTOS)

Provide mechanisms, primitives, and guidelines for building real-time embedded systems Windows CE
Built specifically for embedded systems and appliance market Scalable real-time 32-bit platform Supports Windows API Perfect for systems designed to interface with Internet Preemptive priority scheduling with 256 priority levels per process Kernel is 400 Kbytes Real-time microkernel surrounded by optional processes (resource managers) that provide POSIX and UNIX compatibility
Microkernels typically support only the most basic services Optional resource managers allow scalability from small ROM-based systems to huge multiprocessor systems connected by various networking and communication technologies

Summary
Computation models are distinct from languages Sequential program model is popular
Most common languages like C support it directly

State machine models good for control

Extensions like HCFSM provide additional power PSM combines state machines and sequential programs

QNX

Concurrent process model for multi-task systems

Communication and synchronization methods exist Scheduling is critical

Preemptive process scheduling using FIFO, round-robin, adaptive, or priority-driven scheduling 32 priority levels per process Microkernel < 10 Kbytes and complies with POSIX real-time standard

Dataflow model good for signal processing

Slide 51 CSE466-02au Slide 52

CSE466-02au