Intro Realtime Chapter1
-
Upload
gurudattkulkarni -
Category
Documents
-
view
909 -
download
3
Transcript of Intro Realtime Chapter1
REAL TIME CONCEPTS
• Real time systems are those in which timely is as important as the correctness of the outputs.
• Real time systems do not have to be fast systems
Or
• Any system where a timely response by the computer to external stimuli is vital is a real time system.
• Timely means the real time system runs tasks that have deadlines.
• Deadline – Time constraint
Example : Controlling an aircraft ( Hard real time)
Missile Guidance (Hard real time)
Air traffic control systems ( Hard real time)
Multimedia ( Soft real time )
Real Time Definitions
REAL TIME CONCEPTS
• Example : Data Recording System
Receive Data Store Data Storage
Receive Data Buff Store Data Storage
REAL TIME CONCEPTS
• All practical systems are said to be real time systems, if they meet deadlines.
• A word processor which gives response within certain time (eg:1sec) is considered acceptable.
When is a system Real Time ?
Soft Real Time
The systems whose performance degrades but not destroyed because of not meeting deadlines.
Example: Multimedia Streams
Hard Real Time
The system fails because of not meeting deadlines.
Example: Controlling an aircraft
REAL TIME CONCEPTS
• Definition
Any occurrence that causes the program counter to change non-sequentiality is considered a change of flow-of-control, and thus an event.
Events
receive process
Void *Receive(void*)
{ recvfrom();
pthread_signal();
}
Void *Process(void*)
{ pthread_wait();
process data;
}
REAL TIME CONCEPTS
•Definition
A system is said to be deterministic if, for each possible state and each set of inputs, a unique set of outputs and next state of the system can be determined.
Determinism
idle takeoff Set course
REAL TIME CONCEPTS
• For any physical system certain states exist under which the system is considered to be out of control.
• The software controlling such a system must avoid these states.
Example:
In certain guidance systems for robots or aircraft, rapid rotation through a 180’ pitch angle can cause a physical loss of gyro control.
• The software ability to predict next state of the system given the current state and a set of inputs.
Determinism
REAL TIME CONCEPTS
• Time-Loading, or the utilization factor, is a measure of the percentage of useful processing the computer is doing.
Time Loading
REAL TIME CONCEPTS
• The selection of hardware and software, and the appropriate mix needed for cost effective solution.
• Decide upon existing commercial RTOS or to design a special OS.
• Selection of an software language for system development.
• Maximize fault tolerance and reliability thru design and rigorous testing.
• selection of test and development equipment.
Real Time Design Issues
REAL TIME CONCEPTS
1. Aircraft Navigation System
Examples of Real Time Systems
• Receive x,y,z accelerometer pulses at 5 millisecond rate.
• Receive roll, pitch and yaw angles from a special equipment every 40 millisecond rate.
• Receive temperature at 1 second rate.
• Determine the velocity vector at a 40 millisecond rate.
• Output the true velocity every 1 second to the pilots display.
REAL TIME CONCEPTS
2. Nuclear Plant Monitoring System
Examples of Real Time Systems
• Security event trigger must be responded within a second.
• An event trigger indicates that the nuclear core has reached an over-temperature and this signal must be dealt within a 1 millisecond.
REAL TIME CONCEPTS
3. Airline Reservation System
Examples of Real Time Systems
• Transaction turn-around time must be less than 15 seconds.
• At any time several agents must access the database and book the ticket.
Language Issues
Parameter Passing
• Parameters that are passed by value are typically copied onto stack at run-time, at considerable execution time cost.
• Pascal , C and Ada support this feature.
Pass by Value
Language Issues
Parameter Passing
• Indirect instructions are needed for manipulating variables that are passed by reference.
• takes more time for the execution
• Pascal , C and Ada support this feature.
Pass by Reference
Language Issues
Parameter Passing
• The relative advantages and disadvantages depend upon compiler, coding style, target hardware, type of application code, and size of parameters.
Pass by Reference vs Value
Language Issues
Parameter Passing
• The relative advantages and disadvantages depend upon compiler, coding style, target hardware, type of application code, and size of parameters.
Pass by Reference vs Value
Language Issues
Recursion
• procedure is self referential.
• procedure calls require allocation of storage for parameters, local variables, etc.,
•allocation and deallocation consumes time.
• we need to determine run time memory.
• re-entrant code must be protected by semaphores.
Language Issues
Dynamic Allocation
• Dynamic allocation is important for the construction and maintenance of the stacks needed by the real time operating systems.
• although it is time consuming – it is necessary
Language Issues
Typing
• Each variable and constant be of specific type eg:int, real
• Strongly typed languages prohibit mixing of different types in operations and assignments.
Advantages:
- Avoid the truncation of data.
Language Issues
Exception Handling
• Certain languages provide facilities for dealing with errors or other conditions that arise during program execution.
• During run time when an exception occurs certain code is executed to handle it ( exception handler).
Language Issues
Abstract Data Typing
• Abstract representation of entities.
• Program design easier and clearer.
• Example:- structures and records, enumerated data types
• Does not improve the real-time performance.
Language Issues
Object Oriented Languages
Features: Abstraction
Inheritence
Polymorphism
• poly and inheritence – delay factors
• program written in C++ is 43% slower than C.
• delays result from automatic storage management.
• clearer design and better maintainability.
Chapter 3
Real Time Kernel
Polled Loop Systems
• Polled Loop Systems are the simplest real-time kernel.
• Polled loops allow for fast response to single devices.
• A single repetitive test instruction is used to test a flag.
• If the event has not occurred then the polling continues.
• No Intertask Communication is required because only single task exists.
• Polled loop schemes work well when a single processor is dedicated to handling I/O.
Chapter 3
Real Time Kernel
Polled Loop with Interrupts
• A variation on the polled loop uses a fixed clock interrupt to wait a period of time between when the flag is TRUE and when the flag is set to FALSE.
• Waiting avoids interpreting settling oscillations as events.
• A delay period can be realized with a programmable timer that issues an interrupt after a countdown period.
• while TRUE do
•Begin
•if FLAG = TRUE then begin
•counter = 0;
Chapter 3
Real Time Kernel
Polled Loop with Interrupts
•while TRUE do
•Begin
•if FLAG = TRUE then begin
•counter = 0;
While counter < 3
FLAG = FALSE;
process event;
End
End
Chapter 3
Real Time Kernel
Polled Loop with Interrupts
•Polled loop systems are excellent for high speed data channels.
• The processor is dedicated to handling the data channel.
•Dis:
• waste cpu incase of infrequent event.
Chapter 3
Real Time Kernel
PHASE/STATE DRIVEN CODE
•The processing of the function is broken into discrete segments.
• uses nested is then else statements or finite automata.
• ex: complier- lexical, syntax, code generation etc.,
•Case 1: perform part1;
•Case 2:perform part2;
Chapter 3
Real Time Kernel
Co-routines
•These types of kernels are employed in conjunction with code driven by finite state automata.
• In this scheme two or more processes are coded in the state driven fashion.
• After each phase a call is made to the central dispatcher.
• The dispatcher selects next process to execute. This process continues until the next phase is complete and the central dispatcher is called again.
• processes communicate via global variables.
•Dis: communication via global variables
Chapter 3
Real Time Kernel
INTERRUPT DRIVEN SYSTEMS
• The tasks are scheduled via hardware or software interrupts.
• Dispatching is performed by interrupt handling routines.
• The interrupts may occur at fixed rate – periodically or aperiodically.
•Sporadic tasks - interrupts occur aperiodically.
• fixed rate systems – interrupts occur at fixed frequencies.
• when hardware scheduling is used a clock or external device issues signals.
Chapter 3
Real Time Kernel
CONTEXT SWITCHING
• Context switching is the process of saving and restoring sufficient information for a real time task so that it can be resumed after being interrupted.
• The context is saved to a stack data structure.
Context saving rule:
• Context switching is a major contribution to response times.
• is a factor that we strive to minimize.
• save minimum information necessary to restore
Chapter 3
Real Time Kernel
CONTEXT SWITCHING
• Contents of registers
• pc
• Coprocessor registers
• Memory page registers
•Special variables
• memory mapped I/O location mirror images
• Interrupts are disabled during the critical context switching period.
Chapter 3
Real Time Kernel
Stack Model
• The stack model for context switching is used mostly in embedded systems.
• The context is saved by the interrupt controller.
Chapter 3
Real Time Kernel
Round-Robin Systems
• Several processes are executed sequentially to completion.
• Each task is assigned a time quantum.
• A fixed rate clock is used to initiate an interrupt at a rate corresponding to the time slice.
• The task switches its context after the time quantum.
• The context of the next task is resumed for the execution.
Chapter 3
Real Time Kernel
Preemptive Priority Systems
• A high priority task is said to preempt a lower priority task.
• The systems that use preemption schemes instead of round robin or first come first serve scheduling are called preemptive priority systems.
• The priorities assigned to each interrupt are based on the urgency of the task associated with that interrupt.
• Prioritized interrupts can be either fixed priority or dynamic priority.
• Fixed priority systems are less flexible in that the task priorities cannot be changed.
• Dynamic priority systems can allow the priorities of tasks to change. This feature is particularly important in certain types of threat management systems.
Chapter 3
Real Time Kernel
Preemptive Priority Systems
• Preemptive priority schemes can lead to the hogging of resources by higher priority tasks. This can lead to a lack of available resources for lower priority tasks.
• The lower priority tasks are said to be facing a problem called starvation.
Chapter 3
Real Time Kernel
Rate Monotonic systems
• The priorities are assigned so that the higher the execution frequency , the higher the priority.
• This scheme is common in embedded applications, particularly avionics systems, and has been studied extensively.
• In rate-monotic systems priority inversion may necessarily occur.
Where priority inversion is required
• A low priority process with high frequency of execution is assigned a high priority.
• A high priority task with low frequency of execution is assigned a low priority.
Chapter 3
Real Time Kernel
Rate Monotonic systems
Where priority inversion is required
• A lower priority routine holds a resource using a semaphore that a high priority routine needs.
Process1
semlock();
for I = 0 to 100
a [I] = a[I] + 1*I;
semunlock();
Process2
semlock();
for I = 0 to 100
a [I] = a[I] + 2*I;
semunlock();
Chapter 3
Real Time Kernel
Hybrid systems
• Include interrupts that occur at fixed rates and sporadically.
• Sporadic systems are used to handle critical errors that requires immediate attention, and thus have highest priority.
• Another type of hybrid system found in commercial operating systems is combination of round-robin and preemptive systems.
• In these systems tasks of highest priority can always those of lower priority.
• However, tasks of same priority are ready to run simultaneously, then they run in round-robin fashion.
Chapter 3
Real Time Kernel
6.5 FOREGROUND / BACKGROUND SYSTEMS
• These systems are the most common solution for embedded applications.
• They involve set of real time processes called the foreground and a collection of noninterrupt driven processes called background.
• The foreground tasks run in round-robin, preemptive priority, or combination fashion.
• The background task is fully preemtable by any foreground task and, in sense, represents the lowest priority task in the system.
• All real time systems are special cases of foreground/background systems.
Chapter 3
Real Time Kernel
6.5.1 BACKGROUND Processing
• Any thing that is not time critical.
• Background process is the process with the lowest priority.
• The rate at which the background process runs is ver low and depends upon the time-loading factor.
• if “ p” time loading factor for all foreground processes.
• if “ e” is the execution time of background process.
• then background process execution period “ t” is given by
t = e / (1-p)
Examples: Self testing in the background.
display updates.
Chapter 3
Real Time Kernel
6.5.2 Initialization
• Disable Interrupts
• Set up Interrupt vectors and stacks
• perform self test
• perform system initialization
• Enable Interrupts
Chapter 3
Real Time Kernel
6.5.3 Real Time Operation
• Foreground/Background systems represent a superset of all rael time solutions.
• They have good response times , since they rely on hardware to perform scheduling.
Drawback
• Interfaces to complicated devices and networks must be written.
• this procedure can be tedious and prone to error.
Chapter 3
Real Time Kernel
6.6 FULL FEATURED REAL TIME OPERATING SYSTEMS
• Foreground/Background systems can be extended into an real time OS by adding additional functions such as network interfaces, complicated device drivers, and complex debugging tools.
• such systems rely on RR-preemptive scheduling
• OS – is a high priority task
Chapter 3
Real Time Kernel
6.6.1 Task Control Block Model
• This is the most popular method for implementing commercial, full featured, real time OS.
• It is useful in interactive on line systems where tasks come and go.
• it is used in RR-preemptive systems
6.6.1.1 The Model
• Each task is associated with a context ( pc and regs), an ID, status flag anf priority. These are stored in a structure called TCB. And the collection is stored in list.
6.6.1.2 Task States
• A task can take one of the following states
Executing, Ready, Suspended, Dormant
Chapter 3
Real Time Kernel
6.6.1.3 Task Control Block Model
Executing – After creation
Ready – After time slice
Suspended – After an event
Dormant – After deletion
Chapter 3
Real Time Kernel
6.6.1.3 Task Management
• It is the highest priority task
• Every hardware interrupt and every system level call invokes the real time OS.
•TCB – Linked list
• Suspended States – Linked List
• Table of resources
• Table of resource requests.
•When OS is invoked it checks ready list – if next task is ready for execution
•If eligible – then the TCB of currently executing task moves to the end of the list
• Eligible list is removed from the ready list and added to exec list
Chapter 3
Real Time Kernel
6.6.1.3 Task Management
• It also checks status of resources in suspended list.
• if a task is suspended on a resource it enters ready state.
Chapter 4
Inter task Communication
7.1 Buffering Data
• Several mechanisms can be employed to pass data between tasks in a multicasting system.
• The simplest and the fastest mechanism among these is the use of global variables.
• Global variables are contrary to good software engineering practices.
• One of the problems with global variables is that tasks of highest priority can preempt lower-priority routines, corrupting global data.
• The producer can produce the data in buffer and Consumer can read the data from the buffer.
• The buffer can be stack or some other data structure, including an unorganized mass of variables.
Chapter 4
Inter task Communication
7.1.1 Time Relative Buffering
• Double buffering or ping–pong, this technique can be used when time-relative data need to be transferred between cycles of different rates.
•Examples:
- Disk controllers
- Graphical Interfaces
- robot controls
Producer Buffer1 Buffer2 Consumer
Chapter 4
Inter task Communication
7.1.2 Ring Buffers
• A special data structure called a circular queue or ring buffer is used in the same way as a first in first out.
• Ring buffers are easy to manage.
• In the ring buffer, simultaneous I/O are achieved by keeping head and tail pointers.
• Data are loaded at the tail and read from the head.
• An implementation of ring buffer is given below;
Chapter 4
Inter task Communication
7.1.2 Ring Buffers
• procedure read
if head = tail
underflow
else
data = S[head]
head = (head+1) mod N
end
end
Procedure write
if (tail + 1)mod N = head then
overflow
else
s[tail] = data
tail = (tail + 1) mod N
end
End
Chapter 4
Inter task Communication
7. 2 Mail Boxes
• A mail box is a mutually agreed upon memory location that two or more tasks can use to pass data.
• The tasks rely on central scheduler, to write to the location via post operation and read via pend operation.
• The data can be single piece of data or pointer to a larger data structure such as a list or an array.
• In most implementations when the key is taken from the mailbox, the mailbox is emptied.
• Thus several tasks can pend on the mailbox, only one task can receive the key, since key represents the access to a critical resource.
Chapter 4
Inter task Communication
7. 2 Mail Boxes
Procedure post
mailbox gets data
End
Procedure pend
Task reads content of mailbox in data, otherwise suspend the task
End
Task #100 Mail Box Printer
Chapter 4
Inter task Communication
7. 2.3 Ring buffer and queues to control pool of devices
Ring bufferserver server
requestsTo device
Chapter 4
Inter task Communication
7. 3 Critical Regions
• Critical region is a part of code that operates on shared resource.
• Two tasks should not be allowed to enter critical region.
• Simultaneous use of reusable resources is called collision.
• Hence, collision must be prevented.
Chapter 4
Inter task Communication
7. 4 Semaphore
• Semaphore is mechanism used to protect critical region.
• It consists of a variable which acts as a lock to protect resources.
• Two operations wait and signal are used to set or reset the semaphore.
• The primitive operations are defined by the code below;
Procedure wait(S)
while S = TRUE do;
S = TRUE;
End
Chapter 4
Inter task Communication
7. 4.1 mailboxes and Semaphores
•Mail boxes can be used to implement semaphores if semaphore primitives are not provided by the operating system.
• In this, there is an advantage that the pend instruction suspends the waiting process rather than actually waiting on the semaphore.
•Proc wait(T)
pend(temp,T)
End
Proc signal(T)
post(Key,T)
End
Chapter 4
Inter task Communication
7. 4.2 Counting Semaphores
•Used to protect pools of resources.
• Semaphore must be initialized to number of resources.
• Proc Wait(Cs)
•Cs = Cs – 1
•While Cs < 0 do {wait}
End
Proc Signal(Cs)
Cs = Cs + 1
End
Chapter 4
Inter task Communication
7. 4.3 Problems with Semaphores
•LOAD R1,S
•TEST R1,1
•JEQ @1 S = = TRUE ????????
•STORE S,1 S = TRUE
Chapter 4
Inter task Communication
7. 4.4 The Test-and-Set Instruction
• To solve the problem of atomic operation between testing a memory location and storing a specific value in it, some instruction sets provide a test-and-instruction.
• The main idea is to combine testing and storing functions into a single atomic operation.
• The test and set instruction fetches a word from the memory and tests the high order bit, if the bit is zero, it is set to 1 and a condition code of zero is returned. If the bit is 1, a condition code of 1 is returned.
Chapter 4
Inter task Communication
7. 4.4 The Test-and-Set Instruction
Procedure wait(S)
while test-and-set(S) = TRUE do { wait }
S = TRUE;
End
Procedure Signal(S)
begin
S = FALSE;
End
Chapter 4
Inter task Communication
7. 4.4 The Test-and-Set Instruction
The procedure wait would generate the assembly language code that may look like;
loop:
TANDS S
JNE loop
Chapter 4
Inter task Communication
7. 5 Event Flags and Signals
• Certain Languages provide for synchronization mechanisms called event flags.
• These constructs allow for the specification of an event that causes the setting of some flag.
• A second process is designed to react to this flag.
• Event flags in essence represent simulated interrupts, created by the programmer.
• Raising the event transfers flow-of-control to the operating system, which can then invoke the appropriate handler.
• Tasks that are waiting for the occurrence of an event are said to be blocked.
Chapter 4
Inter task Communication
7. 5 Event Flags and Signals
• For Example:
In ANSI-C, the raise and signal facilities are provided.
Signal is a type of s/w interrupt handler, that is used to react to an exception indicated by raise operation.
Chapter 4
Inter task Communication
7. 6 Deadlock
• When tasks are competing for the same set of two or more serially reusable resources, then a deadlock situation may ensue.
• The notion of deadlock is illustrated by an example below;
Procedure Task_A; Procedure Task_B
Wait(S); Wait( R);
Update database file; update Array;
Wait( R); Wait(S);
Update Array; Update database file
Signal(R); Signal( S);
Signal(S) ; Signal( R);
End End
Chapter 4
Inter task Communication
7. 6 Deadlock
• Deadlock is a serious problem because it cannot always be detected through testing.
• Starvation – At least one process satisfies its requirements.
• Deadlock – No processes can satisfy their requirements because all are blocked.
Four Conditions necessary for deadlock situation;
- Mutual Exclusion.
- Circular Wait.
- Hold and Wait.
- No Preemption.
Chapter 4
Inter task Communication
7. 6 Deadlock
Mutual Exclusion : -
• Mutual exclusion applies to those resources that are not sharable.
• Example:- printers, disk devices and output channels.
• Mutual exclusion can be removed by making them sharable to an application task.
Circular Wait : -
• Circular wait condition occurs, when several processes exist that hold resources needed by other processes further down the chain.
• One way to impose an ordering on resources and to force all processes to request resources in increasing order of enumeration.
Chapter 4
Inter task Communication
7. 6 Deadlock
Device Number
Disk 1
Printer 2
Motor Control 3
Monitor 4
Chapter 4
Inter task Communication
7. 6 Deadlock
Hold and Wait: -
• The hold and wait condition occurs when processes request resource and then lock that resource until subsequent resource requests are filled.
• One solution to this problem is to allocate to a process all potentially required resources at the same time.
• This leads to starvation.
• Never allow a process to lock more than one resource at a time.
Chapter 4
Inter task Communication
7. 6 Deadlock
No Preemption: -
• No Preemption can lead to a deadlock.
• If a low priority process holds a resource protected by semaphore S, and if a high priority task interrupts and then waits on semaphore S, the priority inversion will cause the high priority task to wait forever, since the low-priority task can never run to release the resource and signal the semaphore.
• If we allow the higher priority task to preempt the lower one, then the deadlock can be eliminated.
Chapter 4
Inter task Communication
7. 6.1 Deadlock Avoidance
• Several Techniques for avoiding deadlock are available;
- If the semaphores protecting critical regions are implemented by mailboxes with timeouts, then deadlock cannot occur. But starvation occurs.
- Allow preemption- High priority tasks should preempt low priority tasks.
- Eliminate Hold and Wait Condition.
- Another technique uses bankers algorithm. This a slow technique for real time systems.
Chapter 4
Inter task Communication
7. 6.2 Detect and Recover
• One algorithm called ostrich algorithm, advises that the problem must be ignored, if it occurs infrequently.
• Another method says to restart the system completely, this may not be acceptable for some critical systems.
• If a deadlock is detected rollback to a pre-deadlock state.
Chapter 5
System Performance Analysis And Optimization
Key Points of the Chapter
• Noninterrupt driven systems can be analyzed for real time behavior.
• It is impossible predict the performance of interrupt driven systems.
• The performance is studied based on following parameters;
- Response Time:- time between receipt of an interrupt and completion of processing.
- Time Loading :- Percentage of time CPU is doing useful processing
- Memory Loading:- Percentage of memory that is being used.
Chapter 5
System Performance Analysis And Optimization
9.1 Response Time Calculation
• Depends upon the type of the system.
Polled Loops:-
• The response time delay consists of three components
- Hardware delay required to set the software flag by some external device.
- The time required to test the flag.
- The time needed to process the event.
RT = Set flag (nanosecs) + Check flag (micro) + Process Event (milliseconds)
Overlapping events are not allowed.
Chapter 5
System Performance Analysis And Optimization
9.1 Response Time Calculation
Coroutines / Phase Driven code:-
• The response time is calculated by tracing the execution path.
•Proc A
•While TRUE do
•Case phase1:
•Case pahse2:
•Case phase3:
•End
Chapter 5
System Performance Analysis And Optimization
9.1 Response Time Calculation
Interrupt Systems:-
• The response time is calculated by considering following factors;
RT = Interrupt Latency + Context Switch Time +
Schedule Time + Process Interrupt Time.
RT = Li + Cs + Si + Ai
Interrupt Latency: -
•It is the delay when an Interrupt occurs and when the CPU begins reacting to it.
Chapter 5
System Performance Analysis And Optimization
9.1 Response Time Calculation
Interrupt Latency: -
•There are two cases;
• Case 1: When high priority interrupt occurs;
Li = Lp + max { Lm,Ld};
Lp = Propagation delay of the interrupt signal.
- Time when an Ext-device initiates a signal and when it actually latches to Interrupt Controller.
- Depends upon of transit time of electrons across wires.
- and switching speed of Interrupt Controller.
Lm = is the longest completion time of an instruction in the interrupted process.
Chapter 5
System Performance Analysis And Optimization
9.1 Response Time Calculation
Interrupt Latency: -
•There are two cases;
• Case 1: When high priority interrupt occurs;
Li = Lp + max { Lm,Ld};
Ld = Max Time the interrupts are disabled by lower priority tasks.
• Case 2: When low priority interrupt occurs;
Li = Lh
Lh = Time needed to complete high priority routines.
= Impossible to determine.