1

 Models vs. Languages

 State Machine Model
 FSM/FSMD
 HCFSM and Statecharts Language
 Program-State Machine (PSM) Model
 Concurrent Process Model
 Communication
 Synchronization
 Implementation
 Dataflow Model
 Real-Time Systems

2
 Describing embedded system’s 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
 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...

3
 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.
 All that just for crossing the street (and there’s much more)!

4
 How can we (precisely) capture behavior?
 We may think of languages (C, C++), but computation model is the key
 Common computation models:
 Sequential program model
 Statements, rules for composing statements, semantics for executing them
 Communicating process model
 Multiple sequential programs running concurrently
 State machine model
 For control dominated systems, monitors control inputs, sets control
outputs
 Dataflow model
 For data dominated systems, transforms input data streams into output
streams
 Object-oriented model
 For breaking complex software into simpler, well-defined pieces

5
 Poetry Recipe Story State Sequent. Data-
Models machine program flow

Languages English Spanish Japanese C C++ Java

Recipes vs. English Sequential programs vs. C

 Computation models describe system behavior

 Conceptual notion, e.g., recipe, sequential program
 Languages capture models
 Concrete form, e.g., English, C
 Variety of languages can capture one model
 E.g., sequential program model  C,C++, Java
 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

6
 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)

X = 1; X=1

Y = X + 1;

Y=X+1

7
 Partial English description System interface

 Simple elevator “Move the elevator either up or down Unit up

controller to reach the requested floor. Once at Control down

the requested floor, open the door for open

 Request Resolver at least 10 seconds, and keep it open

until the requested floor changes. floor

resolves various floor Ensure the door is never open while req

moving. Don’t change directions Request

requests into single unless there are no higher requests Resolver
b1
buttons

requested floor when moving up or no lower requests inside

... b2 elevator
when moving down…” bN

 Unit Control moves up1 up/down

elevator to this up2

dn2
buttons on
each

requested floor
up3 floor
dn3
...
 Try capturing in C... dnN

8
 System interface
Sequential program model
Partial English description
Inputs: int floor; bit b1..bN; up1..upN-1; dn2..dnN;
Unit up
Outputs: bit up, down, open;
Global variables: int req; “Move the elevator either up or down Control down
void UnitControl() void RequestResolver() to reach the requested floor. Once at open
{ { the requested floor, open the door for
up = down = 0; open = 1; while (1) floor
while (1) { ...
at least 10 seconds, and keep it open
until the requested floor changes. req
while (req == floor); req = ...
open = 0; ... Ensure the door is never open while Request
if (req > floor) { up = 1;} }
else {down = 1;}
moving. Don’t change directions Resolver
b1
buttons
void main() inside
while (req != floor); unless there are no higher requests b2
{ ... elevator
up = down = 0; Call concurrently: when moving up or no lower requests bN
open = 1;
delay(10);
UnitControl() and when moving down…”
RequestResolver() up1 up/down
} }
} up2 buttons on
dn2 each
up3 floor
dn3
You might have come up with something having ...
even more if statements. dnN

9
 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
 E.g., Idle, GoingUp, GoingDn, DoorOpen
 Possible transitions from one state to another based on input
 E.g., req > 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)
 Try it...

10
 UnitControl process using a state machine

req > floor

u,d,o, t = 1,0,0,0 GoingUp !(req > floor)

req > floor timer < 10

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

u,d,o,t = 0,1,0,0 !(req<floor)

GoingDn

u is up, d is down, o is open

req < floor
t is timer_start

11
 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
 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)
 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)

12
 FSMD extends FSM: complex data types and variables for storing data
 FSMs use only Boolean data types and operations, no variables
We described UnitControl as an FSMD
 FSMD: 7-tuple <S, I , O, V, F, H, s0>
req > floor
 S is a set of states {s0, s1, …, sl}
 I is a set of inputs {i0, i1, …, im}
u,d,o, t = 1,0,0,0 GoingUp !(req > floor)

req > floor timer < 10

 O is a set of outputs {o0, o1, …, on} u,d,o,t = 0,0,1,0 !(timer < 10)
Idle DoorOpen
 V is a set of variables {v0, v1, …, v } n
req == floor
req < floor
u,d,o,t = 0,0,1,1

 F is a next-state function (S x I x V → S)u,d,o,t = 0,1,0,0 GoingDn

!(req<floor)

 H is an action function (S → O + V) u is up, d is down, o is open

req < floor
 s0 is an initial state
t is timer_start

 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
 Complete system state now consists of current state, si, and values of all
variables

13
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, req > floor
list associated actions
5. For each state, ensure exclusive u,d,o, t = 1,0,0,0 GoingUp !(req > floor)
and complete exiting transition
conditions req > floor timer < 10

u,d,o,t = 0,0,1,0
• No two exiting conditions can Idle !(timer < 10) DoorOpen
be true at same time req == floor
req < floor
u,d,o,t = 0,0,1,1

– Otherwise nondeterministic
state machine u,d,o,t = 0,1,0,0
!(req<floor)
GoingDn
• One condition must be true at
any given time u is up, d is down, o is open
req < floor
– Reducing explicit transitions t is timer_start

should be avoided when first

learning

14
 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
 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)

15
 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

16
 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
 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...

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

conditions to determine next state UnitControl state machine in sequential programming language
 if(…) {state = …;}

18
#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 S0’s actions here & Insert transitions Ti leaving S0:
if( T0’s condition is true ) {state = T0’s next state; /*actions*/ }
if( T1’s condition is true ) {state = T1’s next state; /*actions*/ }
...
if( Tm’s condition is true ) {state = Tm’s next state; /*actions*/ }
break;
S1:
// Insert S1’s actions here
// Insert transitions Ti leaving S1
break;
...
SN:
// Insert SN’s actions here
// Insert transitions Ti leaving SN
break;
}
}
}

19
 Hierarchical/concurrent state machine
model (HCFSM)
 Extension to state machine model to support Without hierarchy With hierarchy
hierarchy and concurrency
 States can be decomposed into another state A1 z
A

machine x w
A1 z
 With hierarchy has identical functionality as y B x y B
Without hierarchy, but has one less transition (z) w
A2 z
 Known as OR-decomposition A2

 States can execute concurrently

 Known as AND-decomposition
 Statecharts Concurrency
 Graphical language to capture HCFSM
 timeout: transition with time limit as condition B
C D
 history: remember last substate OR- C1 D1
decomposed state A was in before x u
transitioning to another state B y v

 Return to saved substate of A when returning C2 D2

from B instead of initial state

20
 req>floor UnitControl

u,d,o = 1,0,0
 FireMode
GoingUp
req>floor
!(req>floor)  When fire is true, move elevator
u,d,o = 0,0,1
Idle timeout(10) DoorOpen u,d,o = 0,0,1 to 1st floor and open door
req==floor fire
u,d,o = 0,1,0
req<floor !(req<floor)
fire
fire
u,d,o = 0,1,0
– w/o hierarchy: Getting messy!
GoingDn FireGoingDn
fire
floor==1 u,d,o = 0,0,1 – w/ hierarchy: Simple!
req<floor floor>1 FireDrOpen
!fire fire With hierarchy
Without hierarchy UnitControl
req>floor NormalMode

u,d,o = 1,0,0 GoingUp

!(req>floor)
req>floor
ElevatorController u,d,o = 0,0,1 u,d,o = 0,0,1
Idle DoorOpen
UnitControl RequestResolver req==floor timeout(10)
req<floor !(req>floor)
NormalMode u,d,o = 0,1,0 GoingDn
...
!fire fire req<floor
FireMode FireMode
fire
FireGoingDn u,d,o = 0,1,0
!fire
floor==1 u,d,o = 0,0,1
floor>1 FireDrOpen
With concurrent RequestResolver
fire

21
 Program-state’s actions can be FSM or ElevatorController

sequential program UnitControl

int req;
RequestResolver
 Designer can choose most appropriate NormalMode
up = down = 0; open = 1; ...
 Stricter hierarchy than HCFSM used in while (1) {
while (req == floor);
req = ...

Statecharts open = 0;
...

if (req > floor) { up = 1;}

 transition between sibling states only, else {down = 1;}
single entry while (req != floor);
open = 1;
 Program-state may “complete” delay(10);
 Reaches end of sequential program code, OR }
}
!fire fire
 FSM transition to special complete substate FireMode
 PSM has 2 types of transitions up = 0; down = 1; open = 0;
 Transition-immediately (TI): taken regardless of while (floor > 1);
up = 0; down = 0; open = 1;
source program-state
 Transition-on-completion (TOC): taken only if
condition is true AND source program-state is
complete • NormalMode and FireMode described as
 SpecCharts: extension of VHDL to capture sequential programs
PSM model • Black square originating within FireMode
 SpecC: extension of C to capture PSM indicates !fire is a TOC transition
model – Transition from FireMode to NormalMode
only after FireMode completed

22
 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
 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
 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

23
  Describes functionality of system in terms of two or more
concurrently executing subtasks
ConcurrentProcessExample() {
x = ReadX()
 Many systems easier to describe with concurrent process
y = ReadY() model because inherently multitasking
Call concurrently:
PrintHelloWorld(x) and  E.g., simple example:
PrintHowAreYou(y)
}  Read two numbers X and Y
PrintHelloWorld(x) {
while( 1 ) {  Display “Hello world.” every X seconds
print "Hello world."
delay(x);  Display “How are you?” every Y seconds
}
}  More effort would be required with sequential program
PrintHowAreYou(x) {
while( 1 ) { or state machine model
print "How are you?"
delay(y);
} Enter X: 1
} Enter Y: 2
Hello world. (Time = 1 s)
PrintHelloWorld
Hello world. (Time = 2 s)
Simple concurrent process example ReadX ReadY How are you? (Time = 2 s)
Hello world. (Time = 3 s)
PrintHowAreYou
How are you? (Time = 4 s)
Hello world. (Time = 4 s)
time ...

Subroutine execution over time Sample input and output

24
 Derivative of concurrent process model Z = (A + B) * (C - D)
 Nodes represent transformations
 May execute concurrently A B C D

 Edges represent flow of tokens (data) from one node to + –

another t1 t2

 May or may not have token at any given time *

 When all of node’s input edges have at least one token,

node may fire Z
Nodes with arithmetic
 When node fires, it consumes input tokens processes transformations
transformation and generates output token
A B C D
 Nodes may fire simultaneously
 Several commercial tools support graphical languages modulate convolve

for capture of dataflow model

t1 t2

transform
 Can automatically translate to concurrent process model for
implementation
Z
 Each node becomes a process Nodes with more complex
transformations

25
 With digital signal-processors (DSPs), data flows at
fixed rate
 Multiple tokens consumed and produced per firing
A B C D
 Synchronous dataflow model takes advantage of this
 Each edge labeled with number of tokens mA mB mC mD

consumed/produced each firing modulate convolve

 Can statically schedule nodes, so can easily use sequential mt1 t1 t2 ct2

program model tt1 tt2

 Don’t need real-time operating system and its overhead transform

 How would you map this model to a sequential tZ

programming language? Try it... Z

 Algorithms developed for scheduling nodes into

“single-appearance” schedules Synchronous dataflow

 Only one statement needed to call each node’s associated

procedure
 Allows procedure inlining without code explosion, thus
reducing overhead even more

26
27
 Consider two examples Heartbeat Monitoring System
having separate tasks B[1..4]
Task 1:
Read pulse
Task 2:
If B1/B2 pressed then

running independently If pulse < Lo then

Activate Siren
Lo = Lo +/– 1
If B3/B4 pressed then

but sharing data

If pulse > Hi then Hi = Hi +/– 1
Heart-beat Activate Siren Sleep 500 ms
pulse Sleep 1 second Repeat
 Difficult to write system Repeat

using sequential
program model
 Concurrent process
Set-top Box
model easier Task 1: Task 2:
Read Signal
Separate sequential
Wait on Task 1
 Separate Audio/Video Decode/output Audio Video
Send Audio to Task 2
programs (processes) for
Repeat
Input Send Video to Task 3
Signal Repeat Task 3: Audio
each task Wait on Task 1
Decode/output Video
 Programs communicate Repeat

with each other

28
 A sequential program, typically an infinite loop
 Executes concurrently with other processes
 We are about to enter the world of “concurrent programming”
 Basic operations on processes
 Create and terminate
 Create is like a procedure call but caller doesn’t wait
 Created process can itself create new processes
 Terminate kills a process, destroying all data
 In HelloWord/HowAreYou example, we only created processes
 Suspend and resume
 Suspend puts a process on hold, saving state for later execution
 Resume starts the process again where it left off
 Join
 A process suspends until a particular child process finishes execution

29
 Processes need to communicate data and Encoded video

signals to solve their computation processA() {

packets

problem // Decode packet

// Communicate packet
to B
 Processes that don’t communicate are just }
}

independent programs solving separate

problems
 Basic example: producer/consumer Decoded video
packets
 Process A produces data items, Process B void processB() {
// Get packet from A
consumes them }
// Display packet

 E.g., A decodes video packets, B display

decoded packets on a screen
 How do we achieve this To display
communication?
 Two basic methods
 Shared memory
 Message passing 30
 Processes read and write shared variables 01: data_type buffer[N];
02: int count = 0;
 No time overhead, easy to implement 03: void processA() {
04: int i;
 But, hard to use – mistakes are common 05:
06:
while( 1 ) {
produce(&data);
 Example: Producer/consumer with a mistake 07:
08:
while( count == N );/*loop*/
buffer[i] = data;
 Share buffer[N], count 09: i = (i + 1) % N;
10: count = count + 1;
 count = # of valid data items in buffer
11: }
 processA produces data items and stores in buffer 12: }
 If buffer is full, must wait 13: void processB() {
14: int i;
 processB consumes data items from buffer 15: while( 1 ) {
 If buffer is empty, must wait 16: while( count == 0 );/*loop*/
17: data = buffer[i];
 Error when both processes try to update count concurrently (lines 10 18: i = (i + 1) % N;
and 19) and the following execution sequence occurs. Say “count” is 19: count = count - 1;
20: consume(&data);
3. 21: }
 A loads count (count = 3) from memory into register R1 (R1 = 3) 22: }
 A increments R1 (R1 = 4) 23: void main() {
24: create_process(processA);
 B loads count (count = 3) from memory into register R2 (R2 = 3) 25: create_process(processB);
 B decrements R2 (R2 = 2) 26: }
 A stores R1 back to count in memory (count = 4)
 B stores R2 back to count in memory (count = 2)
 count now has incorrect value of 2

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

from }

 Receive is blocking, send may or may not

be blocking
 Safer model, but less flexible

32
 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
 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

33
 The primitive mutex is used to ensure critical 01: data_type buffer[N];
02: int count = 0;
sections are executed in mutual exclusion of each 03: mutex count_mutex;
other 04:
05:
void processA() {
int i;
 Following the same execution sequence as before: 06:
07:
while( 1 ) {
produce(&data);
 A/B execute lock operation on count_mutex 08: while( count == N );/*loop*/
09: buffer[i] = data;
 Either A or B will acquire lock 10: i = (i + 1) % N;
 Say B acquires it 11: count_mutex.lock();
12: count = count + 1;
 A will be put in blocked state 13: count_mutex.unlock();
 B loads count (count = 3) from memory into register R2 14:
15: }
}

(R2 = 3) 16: void processB() {

17: int i;
 B decrements R2 (R2 = 2) 18: while( 1 ) {
 B stores R2 back to count in memory (count = 2) 19: while( count == 0 );/*loop*/
20: data = buffer[i];
 B executes unlock operation 21: i = (i + 1) % N;
22: count_mutex.lock();
 A is placed in runnable state again 23: count = count - 1;
 A loads count (count = 2) from memory into register 24: count_mutex.unlock();
25: consume(&data);
R1 (R1 = 2) 26: }
 A increments R1 (R1 = 3) 27: }
28: void main() {
 A stores R1 back to count in memory (count = 3) 29: create_process(processA);
30: create_process(processB);
 Count now has correct value of 3 31: }

34
 Try modeling “req” value of our System interface

elevator controller Unit

Control
up
down

 Using shared memory open

floor
 Using shared memory and mutexes req
Request

 Using message passing Resolver

b1
buttons
inside
... b2 elevator
bN

up1 up/down
up2 buttons on
dn2 each
up3 floor
dn3
...
dnN

35
 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 01: mutex mutex1, mutex2;
 Cannot execute unlock operation so will wait forever 02:
03:
void processA() {
while( 1 ) {
 Example code has 2 different critical sections of 04:
05:
…
mutex1.lock();
code that can be accessed simultaneously 06:
07:
/* critical section
mutex2.lock();
1 */

 2 locks needed (mutex1, mutex2) 08:

09:
/* critical section
mutex2.unlock();
2 */

 Following execution sequence produces deadlock 10: /* critical section 1 */

11: mutex1.unlock();
 A executes lock operation on mutex1 (and acquires it) 12: }
13: }
 B executes lock operation on mutex2( and acquires it) 14: void processB() {
 A/B both execute in critical sections 1 and 2, respectively 15: while( 1 ) {
16: …
 A executes lock operation on mutex2 17: mutex2.lock();
 A blocked until B unlocks mutex2 18: /* critical section 2 */
19: mutex1.lock();
 B executes lock operation on mutex1 20: /* critical section 1 */
 B blocked until A unlocks mutex1 21: mutex1.unlock();
22: /* critical section 2 */
 DEADLOCK! 23: mutex2.unlock();
24: }
 One deadlock elimination protocol requires locking 25: }

of numbered mutexes in increasing order and two-

phase locking (2PL)
 Acquire locks in 1st phase only, release locks in 2nd
phase

36
 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
 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
 More efficient methods
 Join operation, and blocking send and receive discussed earlier
 Both block the process so it doesn’t waste CPU time
 Condition variables and monitors

37
 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
 Process B can now acquire lock on same mutex
 Process B enters critical section
 Computes some value and/or make condition true
 Process B performs signal when condition true
 Causes process A to implicitly reacquire mutex lock
 Process A becomes runnable

38
 2 condition variables Consumer-producer using condition variables
 buffer_empty 01: data_type buffer[N];
02: int count = 0;
 Signals at least 1 free location available in 03: mutex cs_mutex;
04: condition buffer_empty, buffer_full;
buffer 06: void processA() {
 buffer_full 07: int i;
08: while( 1 ) {
 Signals at least 1 valid data item in buffer 09: produce(&data);
10: cs_mutex.lock();
 processA: 11: if( count == N ) buffer_empty.wait(cs_mutex);
13: buffer[i] = data;
 produces data item 14: i = (i + 1) % N;
15: count = count + 1;
 acquires lock (cs_mutex) for critical section 16: cs_mutex.unlock();
17: buffer_full.signal();
 checks value of count 18: }
19: }
 if count = N, buffer is full 20: void processB() {
 performs wait operation on buffer_empty 21: int i;
22: while( 1 ) {
 this releases the lock on cs_mutex allowing 23: cs_mutex.lock();
24: if( count == 0 ) buffer_full.wait(cs_mutex);
processB to enter critical section, consume data 26: data = buffer[i];
item and free location in buffer 27: i = (i + 1) % N;
28: count = count - 1;
 processB then performs signal 29: cs_mutex.unlock();
30: buffer_empty.signal();
 if count < N, buffer is not full 31: consume(&data);
32: }
 processA inserts data into buffer 33: }
 increments count 34: void main() {
35: create_process(processA); create_process(processB);
 signals processB making it runnable if it has 37: }
performed a wait operation on buffer_full

39
 Collection of data and methods or
subroutines that operate on data similar to an Monitor
object-oriented paradigm Monitor

 Monitor guarantees only 1 process can DATA Waiting DATA

execute inside monitor at a time CODE
CODE

 (a) Process X executes while Process Y has to

wait
Process Process
Process Process
X Y
X Y
 (b) Process X performs wait on a condition (a) (b)
 Process Y allowed to enter and execute
Monitor Monitor
DATA Waiting
 (c) Process Y signals condition Process X DATA

waiting on CODE CODE

 Process Y blocked
 Process X allowed to continue executing
Process Process Process Process
X Y
 (d) Process X finishes executing in monitor or (c)
X
(d)
Y

waits on a condition again

 Process Y made runnable again

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

41
 Mapping of system’s
The choice of
functionality onto hardware computational

processors: State
machine
Sequent.
program
Data-
flow
Concurrent
processes
model(s) is based
on whether it
 captured using computational allows the designer
to describe the
model(s) system.

 written in some language(s)

The choice of
 Implementation choice Pascal C/C++ Java VHDL
language(s) is

independent from language(s)

based on whether
it captures the
choice computational
model(s) used by

 Implementation choice based the designer.

on power, size, performance, The choice of

timing and cost requirements implementation is
based on whether it
 Final implementation tested for Implementation A Implementation
B
Implementation
C
meets power, size,
performance and
feasibility cost requirements.

 Also serves as
blueprint/prototype for mass
manufacturing of final product
42
 Can use single and/or general-purpose
processors

Communication Bus
Processor A

 (a) Multiple processors, each executing one Process1

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

 More common
 (b) One general-purpose processor running all
processes

Communication Bus
Processor A

 Most processes don’t use 100% of processor time Process1

Process2 General
 Can share processor time and still achieve (c) Process3 Purpose
necessary execution rates Process4 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
43
 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
}
 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)
 Can convert processes to sequential program with process scheduling right in code
 Less overhead (no operating system)
 More complex/harder to maintain

44
 Different meanings when operating system terminology
 Regular processes
 Heavyweight process
 Own virtual address space (stack, data, code)
 System resources (e.g., open files)
 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
 Small compared to heavyweight processes
 Can be created quickly
 Low cost switching between threads

45
 Multiple processes mapped to single-purpose processors
 Built into processor’s 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

 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

46
 Must meet timing requirements when multiple concurrent
processes implemented on single general-purpose processor
 Not true multitasking
 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)
 Determines which process will be next to run
 Nonpreemptive
 Only determines which process is next after current process finishes
execution
47
 Process with highest priority always selected first by scheduler
 Typically determined statically during creation and dynamically
during execution
 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

48
 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 Rate monotonic
 Usually determined by the description of the system Process Period Priority
 E.g., refresh rate of display is 27 times/sec
A 25 ms 5
 Period = 37 ms B 50 ms 3
 Execution deadline C
D
12 ms 6
100 ms 1
 Amount of time process must be completed by after it has started E 40 ms 4
 E.g., execution time = 5 ms, deadline = 20 ms, period = 100 ms F 75 ms 2
 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 Deadline monotonic
 Process suspended for 14 ms, then runs for the remaining 1 ms
Process Deadline Priority
 Completed within 4 + 14 + 1 = 19 ms which meets deadline of 20 ms
 Without deadline process could be suspended for much longer G 17 ms 5
H 50 ms 2
 Rate monotonic scheduling I 32 ms 3
J
 Processes with shorter periods have higher priority K
10 ms
140 ms
6
1
 Typically used when execution deadline = period L 32 ms 4

 Deadline monotonic scheduling

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

49
 Systems composed of 2 or more cooperating, concurrent processes
with stringent execution time constraints
 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.
 Communication and synchronization between processes for these
systems is critical
 Therefore, concurrent process model best suited for describing these
systems

50
 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
 QNX
 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
 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

51
 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
 Concurrent process model for multi-task
systems
 Communication and synchronization methods exist
 Scheduling is critical
52