FYS 4220 2008 / #5

Real Time and Embedded Data Systems

Multitasking and scheduling of Real Time

processes, some strategies

T.B. Skaali, Department of Physics, University of Oslo)

Some definitions to start with

The scheduler is the component of the kernel that selects
which process to run next. The scheduler (or process scheduler,
as it is sometimes called) can be viewed as the code that
divides the finite resource of processor time between the
runnable processes on a system.
Multitasking operating systems come in two flavors:
cooperative multitasking and preemptive multitasking.
Linux, like all Unix variants and most modern operating
systems, provides preemptive multitasking. In preemptive
multitasking, the scheduler decides when a process is to cease
running and a new process is to resume running. The act of
involuntarily suspending a running process is called preemption.
The time a process runs before it is preempted is
predetermined, and is called the timeslice of the process. The
timeslice, in effect, gives each process a slice of the processor's
time. Managing the timeslice enables the scheduler to make
global scheduling decisions for the system. It also prevents any
one process from monopolizing the system
Conversely, in cooperative multitasking, a process does not stop running
until it voluntary decides to do so. This approach has many shortcomings
T.B. Skaali, Department of Physics, University of Oslo

The Scheduling Challenge

Scheduling is the problem of assigning a set of
processes (tasks) to a set of resources subject to a
set of constraints. Examples of scheduling
constraints include deadlines (e.g., job i must be
completed by time T), resource capacities (e.g.,
limited memory space), precedence constraints on
the order of tasks (e.g., sequencing of cooperating
tasks according to their activities), and priorities on
tasks (e.g., finish job P as soon as possible while
meeting the other deadlines).
There are zillions (well, almost) of computer science papers on
scheduling

T.B. Skaali, Department of Physics, University of Oslo

Pick your own scheduling strategy

The following is a list of common scheduling practices and disciplines (ref Wikipedia):

Borrowed-Virtual-Time Scheduling (BVT)

Completely Fair Scheduler (CFS)
Critical Path Method of Scheduling
Deadline-monotonic scheduling (DMS)
Deficit round robin (DRR)
Earliest deadline first scheduling (EDF)
Elastic Round Robin
Fair-share scheduling
First In, First Out (FIFO), also known as First Come First Served (FCFS)
Gang scheduling
Genetic Anticipatory
Highest response ratio next (HRRN)
Interval scheduling
Last In, First Out (LIFO)
Job Shop Scheduling
Least-connection scheduling
Least slack time scheduling (LST)
List scheduling
Lottery Scheduling
Multilevel queue
Multilevel Feedback Queue
Never queue scheduling
O(1) scheduler
Proportional Share Scheduling
Rate-monotonic scheduling (RMS)
Round-robin scheduling (RR)
Shortest expected delay scheduling
Shortest job next (SJN)
Shortest remaining time (SRT)
Staircase Deadline scheduler (SD)
"Take" Scheduling
Two-level scheduling
Weighted fair queuing (WFQ)
Weighted least-connection scheduling
Weighted round robin (WRR)
Group Ratio Round-Robin: O(1)

T.B. Skaali, Department of Physics, University of Oslo

Wewilldiscussa
fewoftheseinmore
details

Scheduling of RT processes
An absolute requirement in hard Real-Time systems
is that deadlines are met! Missing a deadline may
have catastrophic consequences. This requirement
is the baseline for true RT Operating Systems!
In soft Real-Time systems deadlines may however
occasionally be missed without leading to
acatastropy. For such such applications standard
OSs can be used (Windows, Linux, etc)
Since Linux is popular in many embedded systems, let us have a
quick look at some of its characteristics

T.B. Skaali, Department of Physics, University of Oslo

Scheduling in Linux
A web search on Linux scheduling will give
numerous hits, not least on hacker-type and/or RealTime improvements of the scheduler.
The following pages on Linux 2.6.8.1 have been copied from
http://josh.trancesoftware.com/linux/linux_cpu_scheduler.pdf
in 2007, a reference which is no longer available

Many so-called Real-Time extensions have been

made to Linux over the years, some of them on
commercial basis. Many of them have been made
obsolete due to the continous improvement of Linux.

T.B. Skaali, Department of Physics, University of Oslo

Linux 2.6.8.1

1/2

Linux2.6.8.1Schedulerstaticpriorities:
Alltaskshasastaticpriority,thenicevalue.Thenicevaluesrangefrom
20to19,thehighervaluebeinglowerpriority(nicer).

T.B. Skaali, Department of Physics, University of Oslo

Linux 2.6.8.1

T.B. Skaali, Department of Physics, University of Oslo

2/2

The Linux Completely Fair Scheduler

The Completely Fair Scheduler is the name of a task

scheduler which was merged into the 2.6.23 release of the
Linux kernel. It aims to maximize overall CPU utilization while
maximizing interactive performance. It was written by Ingo
Molnar.
In contrast to the previous O(1) scheduler used in older Linux
2.6 kernels, the CFS scheduler implementation is not based on
run queues. Instead a red-black tree (
http://en.wikipedia.org/wiki/Red-black_tree) implements a
'timeline' of future task execution. Additionally, the scheduler
uses nanosecond granularity accounting, the atomic units by
which an individual process' share of the CPU was allocated
(thus making redundant the previous notion of timeslices). This
precise knowledge also means that no specific heuristics (read
rule of thumb) are required to determine the interactivity of a
process, for example.
Ref. Wikipedia

T.B. Skaali, Department of Physics, University of Oslo

VxWorks multitasking
Multitasking provides the fundamental mechanism
for an application to control and react to multiple,
discrete real-world events. The VxWorks real-time
kernel, wind, provides the basic multitasking
environment. Multitasking creates the appearance of
many threads of execution running concurrently
when, in fact, the kernel interleaves their execution
on the basis of a scheduling algorithm. Each
apparently independent program is called a task.
Each task has its own context, which is the CPU
environment and system resources that the task
sees each time it is scheduled to run by the kernel.
On a context switch, a task's context is saved in the
task control block (TCB). A task's context includes:
T.B. Skaali, Department of Physics, University of Oslo

10

VxWorks multitasking
Task context:

a thread of execution, that is, the task's program counter

the CPU registers and (optionally) floating-point registers
a stack for dynamic variables and function calls
I/O assignments for standard input, output, and error
a delay timer
a timeslice timer
kernel control structures
signal handlers
debugging and performance monitoring values

In VxWorks, one important resource that is not part of a task's context

is memory address space: all code executes in a single common
address space.

T.B. Skaali, Department of Physics, University of Oslo

11

Wind state transitions

T.B. Skaali, Department of Physics, University of Oslo

12

Wind task state diagram

T.B. Skaali, Department of Physics, University of Oslo

13

VxWorks Wind Scheduling

With a preemptive priority-based scheduler, each
task has a priority and the kernel ensures that the
CPU is allocated to the highest priority task that is
ready to run. This scheduling method is preemptive
in that if a task that has higher priority than the
current task becomes ready to run, the kernel
immediately saves the current task's context and
switches to the context of the higher priority task
A round-robin scheduling algorithm attempts to share
the CPU fairly among all ready tasks of the same
priority.

T.B. Skaali, Department of Physics, University of Oslo

14

Whatfollowsaresomepagesonschedulingfrom
thebookbyBurns&Wellings,withafewadd
ons.

T.B. Skaali, Department of Physics, University of Oslo

15

Scheduling

In general, a scheduling scheme provides two features:

An algorithm for ordering the use of system resources (in
particular the CPUs)
A means of predicting the worst-case behaviour of the system
when the scheduling algorithm is applied

The prediction can then be used to confirm the temporal

requirements of the application

Simple Process Model

The application is assumed to consist of a fixed set of

processes
All processes are periodic, with known periods
The processes are completely independent of each
other
All system's overheads, context-switching times and so
on are ignored (i.e, assumed to have zero cost)
All processes have a deadline equal to their period (that
is, each process must complete before it is next
released)
All processes have a fixed worst-case execution time

Standard Notation
B
C
D
I
J
N
P
R
T
U
a-z

Worst-case blocking time for the process (if applicable)

Worst-case computation time (WCET) of the process
Deadline of the process
The interference time of the process
Release jitter of the process
Number of processes in the system
Priority assigned to the process (if applicable)
Worst-case response time of the process. When process terminates!
Minimum time between process releases (process period)
The utilization of each process (equal to C/T)
The name of a process

Process-Based Scheduling

Scheduling approaches discussed here

Fixed-Priority Scheduling (FPS)
Earliest Deadline First (EDF)
Value-Based Scheduling (VBS)

Fixed-Priority Scheduling (FPS)

This is the most widely used approach and is the main

focus of this course
Each process has a fixed, static, priority which is
computer pre-run-time
The runnable processes are executed in the order
determined by their priority
In real-time systems, the priority of a process is
derived from its temporal requirements, not its
importance to the correct functioning of the system or its
integrity

Earliest Deadline First (EDF) Scheduling

The runnable processes are executed in the order

determined by the absolute deadlines of the processes
The next process to run being the one with the shortest
(nearest) deadline
Although it is usual to know the relative deadlines of
each process (e.g. 25ms after release), the absolute
deadlines are computed at run time and hence the
scheme is described as dynamic

Value-Based Scheduling (VBS)

If a system can become overloaded then the use of

simple static priorities or deadlines is not sufficient; a
more adaptive scheme is needed
This often takes the form of assigning a value to each
process and employing an on-line value-based
scheduling algorithm to decide which process to run
next

Preemption and Non-preemption

With priority-based scheduling, a high-priority process may

be released during the execution of a lower priority one
In a preemptive scheme, there will be an immediate switch
to the higher-priority process
With non-preemption, the lower-priority process will be
allowed to complete before the other executes
Preemptive schemes enable higher-priority processes to be
more reactive, and hence they are preferred
Alternative strategies allow a lower priority process to
continue to execute for a bounded time
These schemes are known as deferred preemption or
cooperative dispatching
Schemes such as EDF and VBS can also take on a preemptive or non pre-emptive form

FPS and Rate Monotonic Priority Assignment

Each process is assigned a (unique) priority based on

its period; the shorter the period, the higher the priority
I.e, for two processes i and j,
T i T j Pi P j
This assignment is optimal in the sense that if any
process set can be scheduled (using pre-emptive
priority-based scheduling) with a fixed-priority
assignment scheme, then the given process set can
also be scheduled with a rate monotonic assignment
scheme
Note, priority 1 is here the lowest (least) priority. For
VxWorks Wind priority the scale is inverted!

Rate-monotonic scheduling

Theorem:

Given a set of periodic tasks and

preemptive priority scheduling, then
assigning priorities such that the tasks
with shorter periods have higher
priorities (rate-monotonic), yields an
optimal scheduling algorithm.

Liu, C.L and Layland, J.W., Scheduling Algorithms

for Multiprogramming in a Hard Real-Time
Environment, journal of the ACM, Vol. 20, No. 1,
1973
FYS 4220 ABB 2004

25

Example Priority Assignment

Process
a
b
c
d
e

Period, T
25
60
42
105
75

Priority, P
5
3
4
1
2

Note,onlyrelativepriorityvaluesarerelevant

Utilisation-Based Analysis

For D=T task sets only

A simple, sufficient but not necessary, schedulability test
exists:
N

Ci
1/ N
U
N (2
1)
i 1 Ti
Liu and Layland

U 0.69 as N

Utilization Bounds
N
1
2
3
4
5
10

Utilization bound
100.0%
82.8%
78.0%
75.7%
74.3%
71.8%

Approaches 69.3% asymptotically

Process Set A
Process Period ComputationTime Priority Utilization
T
C
P
U
a
b
c

50
40
30

12
10
10

1
2
3

0.24
0.25
0.33

The combined utilization is 0.82 (or 82%)

This is above the threshold for three processes (0.78)
and, hence, this process set fails the utilization test

Time-line for Process Set A

Process
a

10of12

Process Release Time

10of10

Process Completion Time

Deadline Met
Process Completion Time
Deadline Missed

10of10

10of10

Preempted

10of10

Executing

10

20

30

40

50

60

Time
Note!Processchasthehighestpriority

Process Set B
Process Period ComputationTime Priority Utilization
T
C
P
U
a
b
c

80
40
16

32
5
4

1
2
3

0.400
0.125
0.250

The combined utilization is 0.775

This is below the threshold for three processes (0.78)
and, hence, this process set will meet all its deadlines

Process Set C
Process Period ComputationTime Priority Utilization
T
C
P
U
a
b
c

80
40
20

40
10
5

1
2
3

0.50
0.25
0.25

The combined utilization is 1.0

This is above the threshold for three processes (0.78)
but the process set will meet all its deadlines
Well, the overhead (context switching, clock interrupt handling
etc) has been defined as zero!!

Time-line for Process Set C

Process
a

5of40

20of40

25of40

10of10

5of5

10of10

5of5

10

40of40

20

5of5

30

40

5of5

50

60

70

Time
Note!Processchasthehighestpriority

80

Utilization-based Test for EDF

Ci

1
i 1 T
i
N

A much simpler test

Superior to FPS; it can support high utilizations. However

FPS is easier to implement as priorities are static
EDF is dynamic and requires a more complex run-time system
which will have higher overhead
It is easier to incorporate processes without deadlines into FPS;
giving a process an arbitrary deadline is more artificial
It is easier to incorporate other factors into the notion of priority
than it is into the notion of deadline
During overload situations
FPS is more predictable; Low priority process miss their deadlines first
EDF is unpredictable; a domino effect can occur in which a large
number of processes miss deadlines

Response-Time Analysis
Here task i's worst-case response time, R, is calculated
first and then checked (trivially) with its deadline

R D
i
i
Ri Ci I i

Where I is the interference (CPU utilization) from higher

priority tasks
a

5of40

b
c

interference

20of40

10of10

5of5

40of40

10of10

5of5

10

25of40

20

5of5

30

40

5of5

50

60

70

Note!Processchasthehighestpriority

80

Calculating R
During R, each higher priority task j will execute a number of
times:

Ri
Number of Releases
Tj
The ceiling function gives the smallest integer greater than the fractional
number on which it acts. So the ceiling of 1/3 is 1, of 6/5 is 2, and of 6/3 is 2.

Total interference is given by:

Ri
Cj
Tj

Response Time Equation

Ri
Ri Ci
Cj

jhp ( i ) T
j
Where hp(i) is the set of tasks with priority higher than task i
Solve by forming a recurrence relationship:

win 1

win
Ci
Cj

jhp ( i )
Tj

0
1
2
n
w
,
w
,
w
,...,
w
The set of values i i i
i ,.. is monotonically non decreasing
When win win 1 the solution to the equation has been found, wi0
must not be greater that Ri (e.g. 0 or Ci )

Response Time Algorithm

for i in 1..N loop -- for each process in turn
n := 0

win : Ci
loop
n 1
calculate new wi
n 1
n
if wi wi then
Ri win
exit value found
end if
n 1
if wi Ti then
exit value not found
end if
n := n + 1
end loop
end loop

ImplementedintheFYS4220VxWorksprogramFPS_analysis.c

Process Set D
Process
a
b
c

Period
T
7
12
20

ComputationTime
C
3
3
5

Priority
P
3
2
1

wb0 3
Ra 3

3
w 3
36

7
1
b

6
w 3
36

7
Rb 6
2
b

wc0 5
5
5
wc1 5
3

3 11

7
12
11
11
wc2 5
3

3 14

7
12
14
3

wc3 5

14
12 3 17

17
17
w 5
3
3 20

7
12
20
20
5
wc 5
3
3 20

7
12
Rc 20
4
c

Response Time Analysis coded for VxWorks

The program analyses the process set D
Code not shown here, only printouts

T.B. Skaali, Department of Physics, University of Oslo

41

Response Time Analysis coded for VxWorks

Process P1 :

T.B. Skaali, Department of Physics, University of Oslo

42

Response Time Analysis coded for VxWorks

Process P2 :

T.B. Skaali, Department of Physics, University of Oslo

43

Response Time Analysis coded for VxWorks

Process P3 :

T.B. Skaali, Department of Physics, University of Oslo

44

Revisit: Process Set C

Process Period ComputationTime Priority Response time
T
C
P
R
a
b
c

80
40
20

40
10
5

1
2
3

80
15
5

The combined utilization is 1.0

This was above the ulilization threshold for three
processes (0.78), therefore it failed the test
The response time analysis shows that the process set
will meet all its deadlines
RTA is necessary and sufficient

Response Time Analysis

Is sufficient and necessary

If the process set passes the test they will meet all their
deadlines; if they fail the test then, at run-time, a
process will miss its deadline (unless the computation
time estimations themselves turn out to be pessimistic)

Worst-Case Execution Time - WCET

Obtained by either measurement or analysis

The problem with measurement is that it is difficult to be

sure when the worst case has been observed

The drawback of analysis is that an effective model of

the processor (including caches, pipelines, memory wait
states and so on) must be available

WCET Finding C
Most analysis techniques involve two distinct activities.

The first takes the process and decomposes its code

into a directed graph of basic blocks
These basic blocks represent straight-line code.
The second component of the analysis takes the
machine code corresponding to a basic block and uses
the processor model to estimate its worst-case
execution time
Once the times for all the basic blocks are known, the
directed graph can be collapsed
VxWorks: next page

VxWorks timexLib
timexLib

NAME
timexLib - execution timer facilities
ROUTINES
timexInit( ) - include the execution timer library
timexClear( ) - clear the list of function calls to be timed
timexFunc( ) - specify functions to be timed
timexHelp( ) - display synopsis of execution timer facilities
timex( ) - time a single execution of a function or functions
timexN( ) - time repeated executions of a function or group of functions
timexPost( ) - specify functions to be called after timing
timexPre( ) - specify functions to be called prior to timing
timexShow( ) - display the list of function calls to be timed

DESCRIPTION
This library contains routines for timing the execution of programs, individual
functions, and groups of functions. The VxWorks system clock is used as a time
base. Functions that have a short execution time relative to this time base can
be called repeatedly to establish an average execution time with an acceptable
percentage of error.

T.B. Skaali, Department of Physics, University of Oslo

49

Sporadic Processes

Sporadics processes have a minimum inter-arrival time

They also require D<T
The response time algorithm for fixed priority scheduling
works perfectly for values of D less than T as long as
n 1
W
the stopping criteria becomes i Di
It also works perfectly well with any priority ordering
hp(i) always gives the set of higher-priority processes

Hard and Soft Processes

In many situations the worst-case figures for sporadic

processes are considerably higher than the averages
Interrupts often arrive in bursts and an abnormal sensor
reading may lead to significant additional computation
Measuring schedulability with worst-case figures may
lead to very low processor utilizations being observed in
the actual running system

General Guidelines
Rule 1 all processes should be schedulable using
average execution times and average arrival rates
Rule 2 all hard real-time processes should be
schedulable using worst-case execution times and worstcase arrival rates of all processes (including soft)

A consequent of Rule 1 is that there may be situations in

which it is not possible to meet all current deadlines
This condition is known as a transient overload
Rule 2 ensures that no hard real-time process will miss
its deadline
If Rule 2 gives rise to unacceptably low utilizations for
normal execution then action must be taken to reduce
the worst-case execution times (or arrival rates)

Aperiodic Processes

These do not have minimum inter-arrival times

Can run aperiodic processes at a priority below the
priorities assigned to hard processes, therefore, they
cannot steal, in a pre-emptive system, resources from
the hard processes
This does not provide adequate support to soft
processes which will often miss their deadlines
To improve the situation for soft processes, a server can
be employed.
Servers protect the processing resources needed by
hard processes but otherwise allow soft processes to
run as soon as possible.
POSIX supports Sporadic Servers
http://faculty.cs.tamu.edu/bettati/Courses/663/2007C/Slides/aperiodic_sporadic.pdf
http://www.usenix.org/publications/login/standards/22.posix.html

Process Interactions and Blocking

If a process is suspended waiting for a lower-priority

process to complete some required computation then
the priority model is, in some sense, being undermined

It is said to suffer priority inversion

If a process is waiting for a lower-priority process, it is

said to be blocked

Priority Inversion

To illustrate an extreme example of priority inversion,

consider the executions of four periodic processes: a, b, c
and d; and two resources: Q and V

Process
a
b
c
d

Priority
1
2
3
4

Execution Sequence
EQQQQE
EE
EVVE
EEQVE

Release Time
0
2
2
4

Example of Priority Inversion

Process
d
c
b
a
0

10

12

14

Executing

Preempted

Executing with Q locked

Blocked

Executing with V locked

16

18

Priority Inheritance
If process p is blocking process q, then p runs with q's
priority. In the diagram below, q corresponds to d, while
both a and c can be p
Process

d(q)
c
b
a
0

10

12

14

16

18

Priority Ceiling Protocols

Two forms

Original ceiling priority protocol

Immediate ceiling priority protocol
Will not be discussed further here

POSIX

POSIX supports priority-based scheduling, and has options to

support priority inheritance and ceiling protocols
Priorities may be set dynamically
Within the priority-based facilities, there are four policies:
FIFO: a process/thread runs until it completes or it is blocked
Round-Robin: a process/thread runs until it completes or it is blocked
or its time quantum has expired
Sporadic Server: a process/thread runs as a sporadic server
OTHER: an implementation-defined

For each policy, there is a minimum range of priorities that

must be supported; 32 for FIFO and round-robin
The scheduling policy can be set on a per process and a per
thread basis

POSIX

Threads may be created with a system contention

option, in which case they compete with other system
threads according to their policy and priority
Alternatively, threads can be created with a process
contention option where they must compete with other
threads (created with a process contention) in the parent
process
It is unspecified how such threads are scheduled relative to
threads in other processes or to threads with global contention

A specific implementation must decide which to support

Other Facilities
POSIX allows:

priority inheritance to be associated with mutexes

(priority protected protocol= ICPP)
message queues to be priority ordered
functions for dynamically getting and setting a thread's
priority
threads to indicate whether their attributes should be
inherited by any child thread they create