ASSIGNMENT 3

RE AL TIME SYSTEM AND SOFTWARE

Submitted To– Submitted By-

Lect. Gargi Sharma Surendra
MCA 4th SEM
D3804A15
10806601
Declaration:

I declare that this assignment is my individual work. I have not

copied from any other student’s work or from any other source
except where due acknowledgment is made explicitly in the
text, nor has any part been written for me by another person.

Student’s
Signature:
surendra

Evaluator’s comments:
________________________________________________________________
_____

Marks obtained: ___________ out of ______________________

Content of Homework should start from this page only:

 Part-A

1. Explain using an appropriate example as to why a critical resource

can get corrupted if the task using it is pre-empted, and then another
task is granted use of resources.

Answer: In many applications, real time tasks need to share some

resources among themselves. The task that is using a resource, can not
immediately hand over the resource to another task that requests the
resource at any arbitrary point in time; but it can do so only after it
completes its use of the resource. If a task is pre-empted before it
completes using the resource, then the resource can become corrupted.

Examples of such resources are files, devices and certain data structures.

Sharing of resources among tasks requires a different set of rules,

compared to the rules used for sharing resources such as a CPU among
tasks. CPU is a serially reusable resource. So that two different tasks
cannot run on a CPU at the same time. An executing task can be
preempted and restarted at a later time without any problem.

2. Define the term priority inversion and unbounded priority inversion

as used in real time operating systems. Is it possible to device a
resource sharing protocol which can guarantee that no task
undergoes: (i) Priority inversion (ii) unbounded priority inversion.
Justify your answer?

ANSWER:

The priority inversion is the state when a lower priority task is holding
resource and the higher priority task needs that resource which is already held
by lower priority task. Then the higher priority task waiting until the resource is
not released by lower priority task. So the higher priority task is gone to under
priority inversion. That’s the simple priority inversion.

The unbounded priority inversion is that when some intermediate priority task
are comes and usage the CPU, they don’t need the resource. The intermediate
task are executed and then the lower priority task is using the resources and
higher priority task is waits for releasing the resource then the higher priority
task is gone under the unbounded priority inversion.

There is TH is higher priority task and TL is lower priority task and holding the
resource R. Then the intermediate tasks T11, T12, T13...... so on are come and
use the CPU and they don’t need the resource. So the TH is waits the
intermediate task and lower priority task. Then the TH is gone under unbound
priority inversion.

 The simplest way to avoid the priority inversion is to prevent pre-

emption (from CPU usage) of lower priority task holding a critical
resource by intermediate priority task.

 This task can be done by increasing the priority level of the lower
priority task to be equal to that of the waiting higher priority task.

 The means is that the lower priority tasks inherit the priority of the
higher priority task.
In the above figure scenario 1 the Ti task is holding a critical resource and the
priority is 5.

In the scenario 2 the other task Tj is requesting the resource and its priority is
10.

Then the ti is inheriting the priority of Tj in scenario 3.

In scenario 4 the ti completed its task and Tj holds the resource.

So there is no priority inversion.

3. Why it is necessary to synchronize the clocks in a distributed real time

systems? Discuss the relative advantage and disadvantage of the
centralized and distributed clock synchronization scheme?

ANSWER: The reason of synchronize the clocks in a distributed real time

systems is that the lake of the synchrony and drift among clocks makes the
time stamping and timeout operation in distributed real time system
meaningless. Therefore, to have meaningful timeout and time stamping
spanning more than one node of distributed system, the clock needs to be
synchronised.

Centralized clock synchronization scheme advantages:

In the centralized clock one is the master clock and other connected clocks
are slave clock. The master clock is connected to every slave clocks. So the
master clock is having all information regarding the slave clock.
 Centralized clock synchronization scheme disadvantages:

There is a problem if slave clocks are wants to share information with other
slave clocks. The cost of centralized clock is high.

Distributed clock synchronization scheme advantages:

These systems allow the sharing of information and resources over a wide
geographic spread and are usually better than traditional centralized systems in
terms of sharing, cost, growth and autonomy.

Distributed clock synchronization scheme disadvantages:

The distributed nature of these systems has to cope with unreliable and insecure
communications and independent failures. These problems become aggravated
when the system is operating critical real time applications such as aerospace
systems, life support systems, nuclear power plants, drive-by-wire systems and
computer-integrated manufacturing systems. Common to all these applications
is the demand for maximum reliability and high performance from computer
controllers, since a single controller failure in these applications can lead to
disaster.

Part-B

4. Explain why algorithms that can be satisfactorily used to schedule real

time tasks on multi processor s often are not satisfactory to schedule
real time tasks on distributed systems, and vice versa?

ANSWER:

These are following four properties that scalable real-time kernels for function
distributed multiprocessors are required to satisfy.

(A) The maximum execution time of an operation that is to synchronize or

communicate with tasks on the same processor (called a local operation) can be
determined independently of the other processors' activities and the number of
contending processors.
(B) The maximum execution time of an operation that is to synchronize or
communicate with tasks on other processors can be determined independently of
the other processors' activities and be bounded with a linear order of the number of
contending processors.

(C) The maximum interrupt response time on each processor can be determined
independently of the other processors' activities and the number of contending
processors.
(D) The interrupt service overhead can be determined independently of the other
processors' activities and the number of contending processors.

5. Explain the time services that a real time operating system (RTOS) is
expected to support. Also briefly highlight how timer services are
implemented in a real time operating system?

ANSWER:
The time services provided by an operating system are based on a software
clock called the system clock maintained by the operating system. The system
clock is maintained by the kernel based on the interrupts received from the
hardware clock. Since hard real-time systems usually have timing constraints in
the micro seconds range, the system clock should have sufficiently fine
resolution1 to support the necessary time services. However, designers of real-
time operating systems find it very difficult to support very fine resolution
system clocks.
In current technology, the resolution of hardware clocks is usually finer than
a nanosecond (contemporary processor speeds exceed 3GHz). But, the clock
resolution being made available by modern real-time operating systems to the
programmers is of the order of several milliseconds or worse.
The hardware clock periodically generates interrupts (often called time service
interrupts). After each clock interrupt, the kernel updates the software clock and
also performs certain other work.

6. Briefly explain why the traditional UNIX kernel is not suitable to be

used in a multiprocessor environment. Explain a spin lock and a
kernel level lock and discuss their use in realization a pre-emptive
kernel.

Answer: One of the biggest problems that real-time programmers face while
using UNIX for real-time application development is that UNIX kernel cannot
be preempted. That is, all interrupts are disabled when any operating system
routine runs.

Let us elaborate this issue.

Application programs invoke operating system services through system calls.

Examples of system calls include the operating system services for creating a
process, interprocess communication, I/O operations, etc. After a system call is
invoked by an application, the arguments given by the application while
invoking the system call are checked. Next, a special instruction called a trap
(or a software interrupt) is executed. As soon as the trap instruction is executed,
the handler routine changes the processor state from user mode to kernel mode
(or supervisor mode), and the execution of the required kernel routine starts.
SPIN LOCK AND A KERNEL LEVEL LOCK:
The most common locking primitive in the kernel is the spinlock, defined in
include/asm/spinlock.h and include/Linux/spinlock.h. The spinlock is a
very simple single-holder lock. If a process attempts to acquire a spinlock
and it is unavailable, the process will keep trying (spinning) until it can
acquire the lock. This simplicity creates a small and fast lock.

Note that spinlocks in Linux are not recursive as they may be in other
operating systems. Spinlocks should be used to lock data in situations
where the lock is not held for a long time—recall that a waiting process will
spin, doing nothing, waiting for the lock.

The kernel is a highly multithreaded environment. Unless some data structure

is private to a single thread of context you have to do appropriate locking for it.

A spin lock is used as an underlying synchronization primitive to guard the queue

of tasks that are waiting to enter an application-level critical section. Another
queue (called a ready queue) of the tasks that are ready to execute on a processor
should also be guarded with a spin lock. Those queues of tasks are shared among
processors and thus must be accessed exclusively by a processor within the run-
time system.

It is ideal from the scalability point of view that the worst-case execution time of
each run-time system service