SEMINAR REPORT

ON

REAL TIME OPERATING SYSTEM

(UNDER THE GUIDANCE OF MS. RSHMA CHAWLA)

SUBMITTED TO: SUBMITTED BY:

MS.GUNJAN ANAND AASTHA DHIMAN

ASSISTANT PROFESSOR 20230036

DEPARTMENT OF COMPUTER APPLICATIONS BCA-1st SEM.

TIMT, YNR.

TILAK RAJ CHADHA INSTITUTE OF MANAGEMENT

AND TECHNOLOGY (TIMT)
Mukand Lal College Eduational Complex, Yamuna nagar

Page 1 of 14
 TABLE OF CONTENTS

1. INTRODUCTION
2. CHARACTERISTICS
3. RESOURCE SHARING
4. DESIGN PHILOSPHIES
5. SCHEDULING
6. TEMPORARILY MASKING/ ISABLING INTERRUPTS
7. MUTEXES
8. SCHEDULERS
9. MEMORY ALLOCATION
10. TYPES OF RTOS
11. ADVANTAGES /DISADVANTAGES
12. COMPARISON OF REGULAR AND REAL TIME OS
13. CONCLUSION
14. REFERENCES

Page 2 of 14
 WHAT IS A REAL TIME OPERATING SYSTEM?

A real-time operating system (RTOS) is an operating system (OS) for real-time computing applications that
processes data and events that have critically defined time constraints. An RTOS is distinct from a time-
sharing operating system, such as Unix, which manages the sharing of system resources with a scheduler, data
buffers, or fixed task prioritization in a multitasking or multiprogramming environment. Processing time
requirements need to be fully understood and bound rather than just kept as a minimum. All processing must occur
within the defined constraints. Real-time operating systems are event-driven and preemptive, meaning the OS can
monitor the relevant priority of competing tasks, and make changes to the task priority. Event-driven systems switch
between tasks based on their priorities, while time-sharing systems switch the task based on clock interrupts.

Fig. 1.1

Real-time operating systems (RTOS) are used in environments where a large number of events, mostly
external to the computer system, must be accepted and processed in a short time or within certain deadlines.
such applications are industrial control, telephone switching equipment, flight control, and real-time
simulations. With an RTOS, the processing time is measured in tenths of seconds. This system is time-bound
and has a fixed deadline. The processing in this type of system must occur within the specified constraints.
Otherwise, This will lead to system failure.

Page 3 of 14
 CHARACTERISTICS OF RTOS

A key characteristic of an RTOS is the level of its consistency concerning the amount of time it takes to accept and
complete an application's task; the variability is 'jitter'. A 'hard' real-time operating system (hard RTOS) has less
jitter than a 'soft' real-time operating system (soft RTOS). A late answer is a wrong answer in a hard RTOS while a
late answer is acceptable in a soft RTOS. The chief design goal is not high throughput, but rather a guarantee of
a soft or hard performance category. An RTOS that can usually or generally meet a deadline is a soft real-time OS,
but if it can meet a deadline deterministically it is a hard real-time OS.

An RTOS has an advanced algorithm for scheduling. Scheduler flexibility enables a wider, computer-system
orchestration of process priorities, but a real-time OS is more frequently dedicated to a narrow set of applications.
Key factors in a real-time OS are minimal interrupt latency and minimal thread switching latency; a real-time OS is
valued more for how quickly or how predictably it can respond than for the amount of work it can perform in a
given period of time.

See the comparison of real-time operating systems for a comprehensive list. Also, see the list of operating
systems for all types of operating systems.

INTERTASK COMMUNICATION AND RESOURCE SHARING

A multitasking operating system like Unix is poor at real-time tasks. The scheduler gives the highest priority to jobs
with the lowest demand on the computer, so there is no way to ensure that a time-critical job will have access to
enough resources. Multitasking systems must manage sharing data and hardware resources among multiple tasks. It
is usually unsafe for two tasks to access the same specific data or hardware resource simultaneously. There are three
common approaches to resolve this problem:

Page 4 of 14
 DESGN PHILOSOPHIES

An RTOS is an operating system in which the time taken to process an input stimulus is less than the time lapsed
until the next input stimulus of the same type.

The most common designs are:

 Event-driven – switches tasks only when an event of higher priority needs servicing; called preemptive
priority, or priority scheduling.
 Time-sharing – switches tasks on a regular clocked interrupt, and on events; called round robin.

Time sharing designs switch tasks more often than strictly needed, but give smoother multitasking, giving the
illusion that a process or user has sole use of a machine.

Early CPU designs needed many cycles to switch tasks during which the CPU could do nothing else useful. Because
switching took so long, early OSes tried to minimize wasting CPU time by avoiding unnecessary task switching.

Fig 1.2

Page 5 of 14
 SCHEDULING

In typical designs, a task has three states:

1. Running (executing on the CPU);

2. Ready (ready to be executed);
3. Blocked (waiting for an event, I/O for example).

Most tasks are blocked or ready most of the time because generally only one task can run at a time per CPU. The
number of items in the ready queue can vary greatly, depending on the number of tasks the system needs to perform
and the type of scheduler that the system uses. On simpler non-preemptive but still multitasking systems, a task has
to give up its time on the CPU to other tasks, which can cause the ready queue to have a greater number of overall
tasks in the ready to be executed state (resource starvation).

Usually, the data structure of the ready list in the scheduler is designed to minimize the worst-case length of time
spent in the scheduler's critical section, during which preemption is inhibited, and, in some cases, all interrupts are
disabled, but the choice of data structure depends also on the maximum number of tasks that can be on the ready list.

Fig 1.3

Page 6 of 14
If there are never more than a few tasks on the ready list, then a doubly linked list of ready tasks is likely optimal. If
the ready list usually contains only a few tasks but occasionally contains more, then the list should be sorted by
priority. That way, finding the highest priority task to run does not require iterating through the entire list. Inserting
a task then requires walking the ready list until reaching either the end of the list, or a task of lower priority than that
of the task being inserted.

Care must be taken not to inhibit preemption during this search. Longer critical sections should be divided into small
pieces. If an interrupt occurs that makes a high priority task ready during the insertion of a low priority task, that
high priority task can be inserted and run immediately before the low priority task is inserted.

The critical response time, sometimes called the flyback time, is the time it takes to queue a new ready task and
restore the state of the highest priority task to running. In a well-designed RTOS, readying a new task will take 3 to
20 instructions per ready-queue entry, and restoration of the highest-priority ready task will take 5 to 30 instructions.

In more advanced systems, real-time tasks share computing resources with many non-real-time tasks, and the ready
list can be arbitrarily long. In such systems, a scheduler ready list implemented as a linked list would be inadequate.

TEMPORARILY MASKING /DISABLING INTERRUPTS

General-purpose operating systems usually do not allow user programs to mask (disable) interrupts, because the user
program could control the CPU for as long as it is made to. Some modern CPUs do not allow user mode code to
disable interrupts as such control is considered a key operating system resource. Many embedded systems and
RTOSs, however, allow the application itself to run in kernel mode for greater system call efficiency and also to
permit the application to have greater control of the operating environment without requiring OS intervention.

On single-processor systems, an application running in kernel mode and masking interrupts is the lowest overhead
method to prevent simultaneous access to a shared resource. While interrupts are masked and the current task does
not make a blocking OS call, the current task has exclusive use of the CPU since no other task or interrupt can take
control, so the critical section is protected. When the task exits its critical section, it must unmask interrupts; pending
interrupts, if any, will then execute. Temporarily masking interrupts should only be done when the longest path
through the critical section is shorter than the desired maximum interrupt latency. Typically this method of
protection is used only when the critical section is just a few instructions and contains no loops. This method is ideal
for protecting hardware bit-mapped registers when the bits are controlled by different tasks.

Page 7 of 14
 MUTEXES

When the shared resource must be reserved without blocking all other tasks (such as waiting for Flash memory to be
written), it is better to use mechanisms also available on general-purpose operating systems, such as a mutex and
OS-supervised inter process messaging. Such mechanisms involve system calls, and usually invoke the OS's
dispatcher code on exit, so they typically take hundreds of CPU instructions to execute, while masking interrupts
may take as few as one instruction on some processors.

A (non-recursive) mutex is either locked or unlocked. When a task has locked the mutex, all other tasks must wait
for the mutex to be unlocked by its owner - the original thread. A task may set a timeout on its wait for a mutex.
There are several well-known problems with mutex based designs such as priority inversion and deadlocks.

Fig 1.4

In priority inversion a high priority task waits because a low priority task has a mutex, but the lower priority task is
not given CPU time to finish its work. A typical solution is to have the task that owns a mutex 'inherit' the priority of
the highest waiting task. But this simple approach gets more complex when there are multiple levels of waiting:
task A waits for a mutex locked by task B, which waits for a mutex locked by task C. Handling multiple levels of
inheritance causes other code to run in high priority context and thus can cause starvation of medium-priority
threads.

In a deadlock, two or more tasks lock mutex without timeouts and then wait forever for the other task's mutex,
creating a cyclic dependency. The simplest deadlock scenario occurs when two tasks alternately lock two mutex, but
in the opposite order. Deadlock is prevented by careful design.

Page 8 of 14
 INTERRUPT HANDLERS AND SCHEDULERS

Since an interrupt handler blocks the highest priority task from running, and since real-time operating systems are
designed to keep thread latency to a minimum, interrupt handlers are typically kept as short as possible. The
interrupt handler defers all interaction with the hardware if possible; typically all that is necessary is to acknowledge
or disable the interrupt (so that it won't occur again when the interrupt handler returns) and notify a task that work
needs to be done. This can be done by unblocking a driver task through releasing a semaphore, setting a flag or
sending a message. A scheduler often provides the ability to unblock a task from interrupt handler context.

An OS maintains catalogues of objects it manages such as threads, mutexes, memory, and so on. Updates to this
catalogue must be strictly controlled. For this reason, it can be problematic when an interrupt handler calls an OS
function while the application is in the act of also doing so. The OS function called from an interrupt handler could
find the object database to be in an inconsistent state because of the application's update. There are two major
approaches to deal with this problem: the unified architecture and the segmented architecture. RTOSs implementing
the unified architecture solve the problem by simply disabling interrupts while the internal catalogue is updated. The
downside of this is that interrupt latency increases, potentially losing interrupts. The segmented architecture does not
make direct OS calls but delegates the OS related work to a separate handler. This handler runs at a higher priority
than any thread but lower than the interrupt handlers. The advantage of this architecture is that it adds very few
cycles to interrupt latency. As a result, OSes which implement the segmented architecture are more predictable and
can deal with higher interrupt rates compared to the unified architecture.

Similarly, the System Management Mode on x86 compatible Hardware can take a lot of time before it returns
control to the operating system.

MEMORY ALLOCATION

Memory allocation is more critical in a real-time operating system than in other operating systems.

First, for stability there cannot be memory leaks (memory that is allocated but not freed after use). The device
should work indefinitely, without ever needing a reboot. For this reason, dynamic memory allocation is frowned
upon. Whenever possible, all required memory allocation is specified statically at compile time.

Another reason to avoid dynamic memory allocation is memory fragmentation. With frequent allocation and
releasing of small chunks of memory, a situation may occur where available memory is divided into several sections
and the RTOS cannot allocate a large enough continuous block of memory, although there is enough free memory.
secondly, speed of allocation is important. a standard memory allocation scheme scans a linked list of indeterminate

Page 9 of 14
length to find a suitable free memory block, which is unacceptable in an rtos since memory allocation has to occur
within a certain amount of time.

Because mechanical disks have much longer and more unpredictable response times, swapping to disk files is not
used for the same reasons as RAM allocation discussed above.

The simple fixed-size-blocks algorithm works quite well for simple embedded systems because of its low overhead.

TYPES OF REAL TIME OPERATING SYSTEM

fig 1.5

1. Hard Real-Time operating system:

These operating systems guarantee that critical tasks be completed within a range of time. For example, a
robot is hired to weld a car body. If the robot welds too early or too late, the car cannot be sold, so it is a
hard real-time system that requires complete car welding by robot hardly on the time., scientific
experiments, medical imaging systems, industrial control systems, weapon systems, robots, air traffic
control systems, etc.
2. Soft real-time operating system:
This operating system provides some relaxation in the time limit.
a. For example – Multimedia systems, digital audio systems etc. Explicit, programmer-defined and
controlled processes are encountered in real-time systems. A separate process is changed with
handling a single external event. The process is activated upon occurrence of the related event
signalled by an interrupt.
b. Multitasking operation is accomplished by scheduling processes for execution independently of
each other. Each process is assigned a certain level of priority that corresponds to the relative
importance of the event that it services. The processor is allocated to the highest priority
processes. This type of schedule, called, priority-based preemptive scheduling is used by real-
time systems.

Page 10 of 14
 3. Firm Real-time Operating System:
RTOS of this type have to follow deadlines as well. In spite of its small impact, missing a deadline can
have unintended consequences, including a reduction in the quality of the product. Example: Multimedia
applications.

ADAVNTAGES OF RTOS

The advantages of real-time operating systems are as follows-

1. Maximum consumption –
Maximum utilization of devices and systems. Thus more output from all the resources.
2. Task Shifting –
Time assigned for shifting tasks in these systems is very less. For example, in older systems, it takes about 10
microseconds. Shifting one task to another and in the latest systems, it takes 3 microseconds.
3. Focus On Application –
Focus on running applications and less importance to applications that are in the queue.
4. Real-Time Operating System In Embedded System –
Since the size of programs is small, RTOS can also be embedded systems like in transport and others.
5. Error Free –
These types of systems are error-free.
6. Memory Allocation –
Memory allocation is best managed in these types of systems.

DISADVANTAGES OF RTOS

The disadvantages of real-time operating systems are as follows-

1. Limited Tasks –
Very few tasks run simultaneously, and their concentration is very less on few applications to avoid errors.
2. Use Heavy System Resources –
Sometimes the system resources are not so good and they are expensive as well.
3. Complex Algorithms –
The algorithms are very complex and difficult for the designer to write on.
4. Device Driver And Interrupt signals –
It needs specific device drivers and interrupts signals to respond earliest to interrupts.
5. Thread Priority –
It is not good to set thread priority as these systems are very less prone to switching tasks.
6. Minimum Switching – RTOS performs minimal task switching

Page 11 of 14
 COMPARISON OF REGULAR AND RTOS

Regular OS Real-Time OS (RTOS)

Complex Simple

Best effort Guaranteed response

Fairness Strict Timing constraints

Average Bandwidth Minimum and maximum limits

Unknown components Components are known

Unpredictable behavior
Predictable behavior

Plug and play RTOS is upgradeable

Page 12 of 14
 CONCLUSION
A real-time operating system provides an immediate response within a predictable timeframe. It is the most obvious
option for systems that need to perform high-priority tasks with critical deadlines.

The major advantage of using an RTOS in a microcontroller is that it makes the development process less painful,
which saves you time and effort.

When compensating for the microcontroller’s limited capabilities, an RTOS undertakes resource management, sorts
out priorities, and keeps task concurrence.

As soon as you have made up your mind about using an RTOS in your project, you can find a suitable solution
among a wide range of various embedded RTOS solutions. There are options for any hardware platform offered by
either proprietary vendors or open-source projects.

It’s always best to try to optimize the development process to make it more efficient and less time-consuming. One
way to do that for many projects is through the use of an RTOS.

Page 13 of 14
 REFERENCES

 https://embeddedcomputing.com/technology/software-and-os/introduction-to-realtime-operating-
systems-rtos
 https://www.sciencedirect.com/topics/engineering/real-time-operating-system
 https://en.wikipedia.org/wiki/Real-time_operating_system
 https://embeddedwala.com/embeddedsystems/rtos-for-embedded-system/rtos-in-embedded-system

Page 14 of 14