Real Time Systems (15EC743)

Module 4 Real time systems(15EC743) Operating systems

MODULE – 4
Operating Systems: Introduction, Real-Time Multi-Tasking OS, Scheduling Strategies, Priority
Structures, Task Management, Scheduler and Real-Time Clock Interrupt Handler, Memory
Management, Code Sharing, Resource Control, Task Co-Operation and Communication, Mutual
Exclusion.

4.1 INTRODUCTION
Specific computer using a particular language can be hidden from the designer. An operating
system for a given computer converts the hardware of the system into a virtual machine with
characteristics defined by the operating system. Operating systems were developed, as their name
implies, to assist the operator in running a batch processing computer; they then developed to
support both real-time systems and multi-access on-line systems. The traditional approach is to
incorporate all the requirements inside a general purpose operating system as illustrated in Figure
4.1. Access to the hardware of the system and to the I/O devices is through the operating system.
In many real-time and multi-programming systems restriction of access is enforced by hardware
and software traps.

MITMysore | Dept of Electronics and Communication Engineering

Figure 4.1: General purpose operating system.

Dept. of ECE, GSSSIETW, Mysuru Page 76

 Real Time Systems (15EC743)
Module 4 Real time systems(15EC743) Operating systems
The operating system is constructed, in these cases, as a monolithic monitor. In single-job
operating systems access through the operating system is not usually enforced; however, it is good
programming practice and it facilitates portability since the operating system entry points remain
constant across different implementations. In addition to supporting and controlling the basic
activities, operating systems provide various utility programs, for example loaders, linkers,
assemblers and debuggers, as well as run-time support for high-level languages.

A general purpose operating system will provide some facilities that are not required in a
particular application, and to be forced to include them adds unnecessarily to the system
overheads. Usually during the installation of an operating system certain features can be selected
or omitted. A general purpose operating system can thus be 'tailored' to meet a specific application
requirement. Recently operating systems which provide only a minimum kernel or nucleus have
become popular; additional features can be added by the applications programmer writing in a
high-level language. This structure is shown in Figure 4.2. In this type of operating system the
distinction between the operating system and the application software becomes blurred. The
approach has many advantages for applications that involve small, embedded systems.

4.2 REAL-TIME MULTI-TASKING OS:

There are many different types of operating systems and until the early 1980s there was a
clear distinction between operating systems designed for use in real-time applications and other
types of operating system. In recent years the dividing line has become blurred. For example,
languages such as Modula-2 enable us to construct multi-tasking real-time applications that run on
top of single-user, single· task operating systems. And operating systems such as UNIX and OS/2
support multi-user, multi-tasking applications. Confusion can arise between multi-user or multi-
programming operating systems and multi-tasking operating systems. The function of a multi-user
operating system is illustrated in Figure 4.4: the operating system ensures that each user can run a
single program as if they had the whole of the computer system for their program.

Although at any given instance it is not possible to predict which user will have the use of
the CPU, or even if the user's code is in the memory, the operating system ensures that one user
program cannot interfere with the operation of another user program. Each user program runs in its
MITMysore | Dept of Electronics and Communication Engineering
own protected environment. A primary concern of the operating system is to prevent one program,

Dept. of ECE, GSSSIETW, Mysuru Page 77

 Real Time Systems (15EC743)
Module 4 Real time systems(15EC743) Operating systems
either deliberately or through error, corrupting another. In a multi-tasking operating system it is
assumed that there is a single user and that the various tasks co-operate to serve the requirements
of the user. Co-operation requires that the tasks communicate with each other and share common
data. This is illustrated in Figure 4.5. In a good multitasking operating system task communication
and data sharing will be regulated so that the operating system is able to prevent inadvertent
communication or data access (that is, arising through an error in the coding of one task) and hence
protect data which is private to a task (note that deliberate interference cannot be prevented the
tasks are assumed to be co-operating).

Figure 4.2: Multitasking operating system.

A real-time multi-tasking operating system has to support the resource sharing and the timing
requirements of the tasks and the functions can be divided as follows:

 Task management: the allocation of memory and processor time (scheduling) to tasks.
 Memory management: control of memory allocation.
 Resource control: control of all shared resources other than memory and CPU time.
 Intertask communication and synchronization: provision of support mechanisms to provide
safe communication between tasks and to enable tasks to synchronize their activities.
MITMysore | Dept of Electronics and Communication Engineering

Dept. of ECE, GSSSIETW, Mysuru Page 78

 Real Time Systems (15EC743)
Module 4 Real time systems(15EC743) Operating systems

Figure 4.3: Typical structure of real-time operating system.

4.3 SCHEDULING STRATEGIES:

If we consider the scheduling of time allocation on a single CPU there are two basic strategies:
 Cyclic.
 Pre-emptive.

Cyclic
The first of these, cyclic, allocates the CPU to a task in turn. The task uses the CPU for as long as
it wishes. When it no longer requires it the scheduler allocates it to the next task in the list. This is
a very simple strategy which is highly efficient in that it minimizes the time lost in switching
between tasks. It is an effective strategy for small embedded 'systems for which the execution
times for each task run are carefully calculated (often by counting the number of machine
instruction cycles for. the task) and for which the software is carefully divided into appropriate
task
MITMysore segments.
| Dept In general this
of Electronics andapproach is too restrictive
Communication since it requires that the task units have
Engineering
similar execution times. It is also difficult to deal with random events using this method.

Dept. of ECE, GSSSIETW, Mysuru Page 79

 Real Time Systems (15EC743)
Module 4 Real time systems(15EC743) Operating systems
Pre-emptive
There are many pre-emptive strategies. All involve the possibility that a task will be
interrupted - hence the term pre-emptive - before it has completed a particular invocation.
A consequence of this is that the executive has to make provision to save the volatile environment
for each task, since at some later time it will be allocated CPU time and will want to continue from
the exact point at which it was interrupted. This process is called context switching and a
mechanism for supporting it is described below. The simplest form of pre-emptive scheduling is to
use a time slicing approach (sometimes called a round-robin method). Using this strategy each task
is allocated a fixed amount of CPU time - a specified number of ticks of the clock – and at the end
of this time it is stopped and the next task in the list is run. Thus each task in turn is allocated an
equal share of the CPU time. If a task completes before the end of its time slice the next task in the
list is run immediately.
The majority of existing RTOSs use a priority scheduling mechanism. Tasks are allocated a
priority level and at the end of a predetermined time slice the task with the highest priority of those
ready to run is chosen and is given control of the CPU. Note that this may mean that the task which
is currently running continues to run. Task priorities may be fixed - a static priority system - or
may be changed during system execution - a dynamic priority system. Dynamic priority schemes
can increase the flexibility of the system, for example they can be used to increase the priority of
particular tasks under alarm conditions. Changing priorities is, however, risky as it makes it much
harder to predict the behavior of the system and to test it. There is the risk of locking out certain
tasks for long periods of time. If the software is well designed and there is adequate computing
power there should be no need to change priorities - all the necessary constraints will be met. If it
is badly designed and/or there are inadequate computing resources then dynamic allocation of
priorities will not produce a viable, reliable system.

4.4 PRIORITY STRUCTURES:

In a real-time system the designer has to assign priorities to the tasks in the system. The priority
will depend on how quickly a task will have to respond to a particular event. An event may be
some activity of the process or may be the elapsing of a specified amount of time.
1. Interrupt level: at this level are the service routines for the tasks and devices which require very
MITMysore
fast| Dept of Electronics
response - measured inand Communication
milliseconds. Engineering
One of these tasks will be the real-time clock task and
clock level dispatcher.

Dept. of ECE, GSSSIETW, Mysuru Page 80

 Real Time Systems (15EC743)
Module 4 Real time systems(15EC743) Operating systems
2. Clock level: at this level are the tasks which require repetitive processing, such as the sampling and
control tasks, and tasks which require accurate timing. The lowest-priority task at this level is the
base level scheduler.
3. Base level: tasks at this level are of low priority and either have no deadlines to meet or are
allowed a wide margin of error in their timing. Tasks at this level may be allocated priorities or
may all run at a single priority level - that of the base level scheduler.

4.4.1 Interrupt level:

As we have already seen an interrupt forces a rescheduling of the work of the CPU and the system
has no control over the timing of the rescheduling. Because an interrupt-generated rescheduling is
outside the control of the system it is necessary to keep the amount of processing to be done by the
interrupt handling routine to a minimum. Usually the interrupt handling routine does sufficient
processing to preserve the necessary information and to pass this information to a further handling
routine which operates at a lower-priority level, either clock level or base level. Interrupt handling
routines have to provide a mechanism for task swapping, that is they have to save the volatile
environment.

MITMysore | Dept of Electronics and Communication Engineering

Dept. of ECE, GSSSIETW, Mysuru Page 81

 Real Time Systems (15EC743)
Module 4 Real time systems(15EC743) Operating systems

Figure 4.4: Priority levels in an RTOS.

4.4.2 Clock level:

One interrupt level task will be the real-time clock handling routine which will be entered
at some interval, usually determined by the required activation rate for the most frequently
required task. Typical values are I to 200 ms. Each clock interrupt is known as a tick and
represents the smallest time interval known to the system. The function of the clock interrupt
handling routine is to update the time-of-day clock in the system and to transfer control to the
dispatcher. The scheduler selects which task is to run at a particular clock tick. Clock level tasks
divide into two categories:
1. CYCLIC: these are tasks which require accurate synchronization with the outside world.
MITMysore | Dept of Electronics and Communication Engineering

Dept. of ECE, GSSSIETW, Mysuru Page 82

 Real Time Systems (15EC743)
Module 4 Real time systems(15EC743) Operating systems
2. DELAY: these tasks simply wish to have a fixed delay between successive repetitions or to delay
their activities for a given period of time.
Cyclic tasks:
The cyclic tasks are ordered in a priority which reflects the accuracy of timing required for the
task, those which require high accuracy being given the highest priority. Tasks of lower priority
within the clock level will have some jitter since they will have to await completion of the higher -
level tasks.
Delay tasks:
The tasks which wish to delay their activities for a fixed period of time, either to allow some
external event to complete (for example, a relay may take 20 ms to close) or because they only
need to run at certain intervals (for example, to update the operator display), usually run at the base
level.

When a task requests a delay its status is changed from runnable to suspend and remains
suspended until the delay period has elapsed. One method of implementing the delay function is to
use a queue of task descriptors, say identified by the name DELAYED. This queue is an ordered
list of task descriptors, the task at the front of the by the name DELAYED. This queue is an
ordered list of task descriptors, the task at the front of the queue being that whose next running
time is nearest to the current time.
4.4.3 Base level:
The tasks at the base level are initiated on demand rather than at some predetermined time
interval. The demand may be user input from a terminal, some process event or some particular
requirement of the data being processed. The way in which the tasks at the base level are
scheduled can vary; one the data being processed. The way in which the tasks at the base level are
scheduled can vary; one simple way is to use time slicing on a round-robin basis. In this method
each task in the runnable queue is selected in turn and allowed to run until either it suspends or the
base level scheduler is again entered. For real-time work in which there is usually some element of
priority this is not a particularly satisfactory solution. It would not be sensible to hold up a task,
which had been delayed waiting for a relay to close but was now ready to run, in order to let the
logging task run.
Most
MITMysore | Dept of real-time systems
Electronics and use a priority strategy
Communication even for the base level tasks. This may be
Engineering
either a fixed level of priority or a variable level. The difficulty with a fixed level of priority is

Dept. of ECE, GSSSIETW, Mysuru Page 83

 Real Time Systems (15EC743)
Module 4 Real time systems(15EC743) Operating systems
in determining the correct priorities for satisfactory operation; the ability to change
priorities dynamically allows the system to adapt to particular circumstances. Dynamic allocation
of priorities can be carried out using a high-level scheduler or can be done on an ad hoc basis
from within specific tasks. The high level scheduler is an operating system task which is able to
examine the use of the system resources; it may for example check how long tasks have been
waiting and increase the priority of the tasks which have been waiting a long time. The difficulty
with the high-level scheduler is that the algorithms used can become complicated and hence the
overhead in running can become significant.

4.5 TASK MANAGEMENT:

The basic functions of the task management module or executive are:
1. To keep a record of the state of each task;
2. To schedule an allocation of CPU time to each task; and
3. To perform the context switch, that is to save the status of the task that is currently. using the CPU
and restore the status of the task that is being allocated CPU time.
In most real-time operating systems the executive dealing with the task management functions is
split into two parts: a scheduler which determines which task is to run next and which keeps a
record of the state of the tasks, and a dispatcher which performs the context switch. Task states:
With one processor only one task can be running at any given time and hence the other
tasks must be in some other state. The number of other states, the names given to the states, and
the transition paths between the different states vary from operating system to operating system. A
typical state diagram is given in Figure6.1 and the various states are as follows (names in
parentheses are commonly are. alternatives):

MITMysore | Dept of Electronics and Communication Engineering

Dept. of ECE, GSSSIETW, Mysuru Page 84

 Real Time Systems (15EC743)
Module 4 Real time systems(15EC743) Operating systems

Figure 4.5: Example of a typical task state diagram.

 Active (running): this is the task which has control of the CPU. It will normally be
the task with the highest priority of the tasks which are ready to run.
 Ready (runnable, on): there may be several tasks in this state. The attribute of the
task and the resources required to run the task must be available for the task to be
placed in the Ready state.
• Suspended (waiting, locked out, delayed): the execution of tasks placed this state
has been suspended because the task requires some resource which is not available or
because the task is waiting for some signal from the plant for example input from the
analog-to-digital converter, or because the task is waiting for the elapse of time.
• Existent (dormant, off): the operating system is aware of the existence of this task,
but the task has not been allocated a priority and has not been made runnable.
• Non-existent (terminated): the operating system has not as yet been made aware of
the existence of this task, although it may be resident in the. Memory of the computer.
MITMysore | Dept of Electronics and Communication Engineering

Dept. of ECE, GSSSIETW, Mysuru Page 85

 Real Time Systems (15EC743)
Module 4 Real time systems(15EC743) Operating systems
4.5.1: Task descriptor:
Information about the status of each task is held in a block of memory by the RTOS. This
block is referred to by various names· task descriptor (TD), process descriptor (PD), task control
block (TCB) or task data block (TDB). The information held in the TD will vary from system to
system, but will typically consist of the following:
 Task identification (TI);
 Task priority (P);
 Current state of task;
 Area to store volatile environment (or a pointer to an area for storing the
volatile environment); and
 Pointer to next task in a list.

4.6 SCHEDULER AND REAL-TIME CLOCK INTERRUPT HANDLES:

The real-time clock handler and the scheduler for the clock level tasks must be carefully designed
as they run at frequent intervals. Particular attention has to be paid to the method of selecting the
tasks to be run at each clock interval. If ached of all tasks were to be carried out then the overheads
involved could become significant.System commands which change task status.

The range of system commands affecting task status varies with the operating system. Typical
states and commands are shown in Figure 6.12 and fuller details of the commands are given in
Table. Note that this system distinguishes between tasks which are suspended awaiting the passage
of time - these tasks are marked as delayed - and those tasks which are waiting for an event or a
system resource these are marked as locked out. The system does not explicitly support base level
tasks; however, the lowest four priority levels of the clock level tasks can be used to create a base
level system A so - called free time executive (FTX) is provided which if used runs at priority
level n - 3 where n is the lowest-priority task number. The FTX is used to run tasks at priority
levels n - 2, n - I and n; it also provides support for the chaining of tasks. The dispatcher is
unaware of the fact that tasks at these three priority levels are being changed; it simply treats
whichever tasks are in the lowest three priority levels as low-priority tasks. Tasks run under the
MITMysore
FTX| Dept ofhave
do not Electronics andsystem
access to the Communication Engineering
commands (except OFFCO1 that is turn task off).

Dept. of ECE, GSSSIETW, Mysuru Page 86

 Real Time Systems (15EC743)
Module 4 Real time systems(15EC743) Operating systems

Figure 4.6: RTOS state diagram.

Dispatcher- search for work:

The dispatcher/scheduler has two entry conditions:

 The real-time clock interrupt and any interrupt which signals the completion of an
input/output request;
 A task suspension due to a task delaying, completing or requesting an input/output transfer.

In response to the first condition the scheduler searches for work starting with the highest-
priority task and checking each task in priority order (see Figure 6.14). Thus if tasks with a high
repetition rate are given a high priority they will be treated as if they were clock level tasks, that is
they will be run first during each system clock period. In response to the second condition a search
for work is started at the task with the next lowest priority to the task which has just been running.
There cannot be another higher-priority task ready to run since a higher-priority task becoming
ready always pre-empts a lower-priority-running task. The system commands for task management
are issued as calls from the assembly level language and the parameters are passed either in the
MITMysore
CPU| Dept of Electronics
registers and
or as a control Communication
word Engineering
immediately following the call statement.

Dept. of ECE, GSSSIETW, Mysuru Page 87

 Real Time Systems (15EC743)
Module 4 Real time systems(15EC743) Operating systems
4.7 MEMORY MANAGEMENT:
Since the majority of control application software is static - the software is not dynamically created
or eliminated at run-time - the problem of memory management is simpler than for multi-
programming, on-line systems. Indeed with the cost of computer hardware, both processors and
memory, reducing many control applications use programs which are permanently resident in fast
access memory. With permanently resident software the memory can be divided as shown in
Figure. The user space is treated as one unit and the software is linked and loaded as a single
program into the user area. The information about the various tasks is conveyed to the operating
system by means of a create task statement. Such a statement may be of the form the exact form of
the statement will depend on the interface between the high-level language and the operating
system. An alternative arrangement is shown in Figure.

The available memory is divided into predetermined segments and the tasks are loaded
individually into the various segments. The load operation would normally be carried out using to
command processor. With this type of system the entries in the TD (or the operation system tables)
have to be made from the console using a memory examine as change facility. Divided
(partitioned) memory was widely used in many early real-time operating systems and it was
frequently extended to allow several tasks to share on:
partition; the tasks were kept on the backing store and loaded into the appropriate partition
when required. There was of course a need to keep any tasks in which timing was crucial (hard
time constraint tasks) in fast access memory permanent other tasks could be swapped
between fast memory and backing store. The difficulty with this method is, of course, in choosing
the best mix of partition sizes. The partition size and boundaries have to be determined at system
generation.

MITMysore | Dept of Electronics and Communication Engineering

Figure 4.7: Non-partitioned memory.

Dept. of ECE, GSSSIETW, Mysuru Page 88

 Real Time Systems (15EC743)
Module 4 Real time systems(15EC743) Operating systems

Figure 4.8: Partitioned memory.

4.8 CODE SHARING:

In many applications the same actions have to be carried out in several different tasks. In a
conventional program the actions would be coded as a subroutine and one copy of the subroutine
would be included in the program. In a multi-tasking system each task must have its own copy of
the subroutine or some mechanism must be provided to prevent one task interfering with the use of
the code by another task. The problems which can arise are illustrated in Figure 6.20. Two tasks
share the subroutine S. If task A is using the subroutine but before it finishes some even occurs
which causes a rescheduling of the tasks and task B runs and uses the subroutine, then when a
return is made to task A, although it will begin to use subroutine S again at the correct place, the
values of locally held data will have been changed and will reflect the information processed
within the subroutine by task B.

Two methods can be used to overcome this problem:

• serially reusable code; and
• re-entrant code.

MITMysore | Dept of Electronics and Communication Engineering

Dept. of ECE, GSSSIETW, Mysuru Page 89

 Real Time Systems (15EC743)
Module 4 Real time systems(15EC743) Operating systems

Figure 4.9: Sharing a subroutine in multi-tasking system.

4.8.1 Serially reusable code:

As shown in Figure, some form of lock mechanism is placed at the beginning of the routine
such that if any task is already using the routine the calling task will not be allowed entry until the
task which is using the routine unlocks it. The use of a lock mechanism to protect a subroutine is
an example of the need for mechanisms to support mutual exclusion when constructing an
operating system.

MITMysore | Dept of Electronics and Communication Engineering

Figure 4.10: Serially reusable code.

Dept. of ECE, GSSSIETW, Mysuru Page 90
 Real Time Systems (15EC743)
Module 4 Real time systems(15EC743) Operating systems
4.8.2 Re-entrant code:

If the subroutine-can be coded such that it does not hold within it any data that is it is
purely code - any intermediate results are stored in the calling task or in a stack associated with the
task - then the subroutine is said to be re-entrant. Figure shows an arrangement which can be used:
the task descriptor for each task contains a pointer to a data area - usually a stack area - which is
used for the storage of all information relevant to that task when using the subroutine. Swapping
between tasks while they are using the subroutine will not now cause any problems since the
contents of the stack pointer will be saved with the volatile environment of the task and will be
restored when the task resumes.

All accesses to data by the subroutine will be through the stack and hence it will
automatically manipulate the correct data. Re-entrant routines can be shared between several tasks
since they contain no data relevant to a particular task and hence can be stopped and restarted at a
different point in the routine without any loss of information. The data held in the working
registers of the CPU is stored in the relevant task descriptor when task swapping takes place.
Device drivers in conventional operating systems are frequently implemented using re-entrant
code. The PID control1er code segment uses the information in the LOOP descriptor and the T
ASK to calculate the control value and to send it to the control1er. The actual task is made up of
the LOOP descriptor, the TASK segment and the PID control code segment. The addition of
another loop to the system requires the provision of new loop descriptors; the actual PID control
code remains unchanged.

MITMysore | Dept of Electronics and Communication Engineering

Figure 4.11: Use of re-entrant code for sharing.

Dept. of ECE, GSSSIETW, Mysuru Page 91

 Real Time Systems (15EC743)
Module 4 Real time systems(15EC743) Operating systems
4.9 RESOURCE CONTROL: AN EXAMPLE OF AN INPUT/OUTPUT
SUBSYSTEM (IOSS)
One of the most difficult areas of programming is the transfer of information to and from external
devices. The availability of a wel1-designed and implemented input/output subsystem (LOSS) in
an operating system is essential for efficient programming. The LOSS handles all the details of the
devices. In a multi-tasking system the LOSS should also deal with all the problems of several tasks
attempting to access the same device. A typical LOSS will be divided into two levels as shown in
Figure. The I/O manager accepts the system calls from the user tasks and transfers the information
contained in the calls to the device control block (DCB) for the particular device.

MITMysore | Dept of Electronics and Communication Engineering

Figure 4.12: General structure of IOSS.

Dept. of ECE, GSSSIETW, Mysuru Page 92

 Real Time Systems (15EC743)
Module 4 Real time systems(15EC743) Operating systems
4.10 TASK CO-OPERATION AND COMMUNICATION:
In real-time systems tasks are designed to fulfill a common purpose and hence they need to
communicate with each other. However, they may also be in competition for the resources of the
computer system and this competition must be regulated. Some of the problems which arise have
already been met in considering the input/output subsystem and they involve:
 Mutual exclusion;
 Synchronization; and
 Data transfer.

4.10.1 Mutual exclusion:

A multi-tasking, operating system allows the sharing of resources between several concurrently
active tasks. This does not imply that the resources can be used simultaneously. The use of some
resources is restricted to only one task at a time. For others, for example a re-entrant code module,
several tasks can be using them at the same time. The restriction to one task at a time has to be
made for resource such as input and output devices; otherwise there is a danger that input intended
for one task could get corrupted by input for another task. Similarly problems can arise if two tasks
share a data area and both tasks can write to the data area.

Recommended book for reading:

nd
1. Real –Time Computer control –An Introduction, Stuart Bennet, 2 Edn. Pearson
Education 2005.

2. Real-Time Systems Design and Analysis, Phillip. A. Laplante, Second Edition, PHI,
2005.

MITMysore | Dept of Electronics and Communication Engineering

Dept. of ECE, GSSSIETW, Mysuru Page 93