rts 3

May 15, 2018 | Author: Surendra Singh Chauhan | Category: Kernel (Operating System), Real Time Computing, Operating System, Thread (Computing), Process (Computing)
Share Embed Donate


Short Description

Download rts 3...

Description

ASSIGNMENT 3 RE AL TIME SYSTEM AND SOFTWARE

Submitted To– Lect. Gargi Sharma

Submitted Submitted BySurendra 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 priori priority ty inversion inversion and and unbounded unbounded priority priority inversi inversion on 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 prior ity 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 preemption (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 necessary to synchroniz synchronizee the clocks clocks in a distribu distributed ted real time 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 Explain why algorit algorithms hms that can can be satisfacto satisfactorily rily used used to schedule schedule real 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 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 Explain the time time services services that a real real time time operating operating system (RTOS) (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 the micr micro o seco second ndss range range,, the the syst system em cloc clock k shou should ld have have suff suffic icie ient ntly ly fine fine resolution1 resolution1 to support the necessary time services. However, designers of realtime 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 hardware clock periodically 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 ar guments 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 t he spinlock, defined in include/asm/spinlock.h and include/Linux/spinlock.h. 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 runtime system. It is ideal from the scalability point of view that the worst-case execution time of  each run-time system service

View more...

Comments

Copyright ©2017 KUPDF Inc.
SUPPORT KUPDF