real time operating systems
play

Real-time Operating Systems Short introduction [GSS7 - PDF document

TDDI04 Concurrent Programming, Operating Systems, and Real-time Operating Systems


  1. TDDI04 ����� ������� ������ Concurrent Programming, Operating Systems, and Real-time Operating Systems ����������������������� ���������������� ��������������� �������������� Real-time Operating Systems ������� ��� Short introduction �� [GSS7 Chapter 19] Acknowledgment: Some slides are by courtesy of Jörgen Hansson, RTSLAB / IDA. The lecture notes are originally compiled by C. Kessler, IDA. Klas Arvidsson, IDA, Linköpings universitet. TDDI04, K. Arvidsson, IDA, Linköpings universitet. RT.2 Example: Controlling flow of cooling What is a Real-time System? water in a nuclear power plant § A real-time system is any information processing system which has to respond to externally generated input stimuli Interface Pipe within a finite and specified period . • Correctness depends not only on the logical result but also Input flow Flow meter the time it was delivered! reading • Failure to respond is as bad as the wrong response! Processing § Many (but not all) real-time systems are embedded systems. Valve (regulator) Output valve • Embedded computer system : angle the computer is a component in a larger engineering Time Computer system. • Ex.: Consumer electronics devices, car control systems, ... TDDI04, K. Arvidsson, IDA, Linköpings universitet. RT.3 TDDI04, K. Arvidsson, IDA, Linköpings universitet. RT.4 Some Misconceptions about Some Misconceptions about Real-Time Systems Real-Time Systems MISCONCEPTION #1: MISCONCEPTION #2: ”Real-time computing is equivalent to fast computing!” ”Advances in hardware performance will solve real-time problems” § CORRECT: Real-time computing aims at predictability foremost, and secondly, efficiency. § CORRECT: Improving hardware performance is always desirable, but does not imply (without support of analysis) that § Predictability : Time-cognizant behavior of the system, i.e ., predictability has been maintained / achieved (e.g., release the system is designed and developed to enforce temporal times of tasks). correctness , preferably by direct awareness and explicit § Most computer architecture techniques improve on the notion of time. average case but may even aggravate the worst case! • Example: Memory access time with caching, TLB TDDI04, K. Arvidsson, IDA, Linköpings universitet. RT.5 TDDI04, K. Arvidsson, IDA, Linköpings universitet. RT.6 1

  2. Utility Function Terminology (Value of result relative to time) § Hard real-time � Hard real-time system: • systems where it is absolutely imperative that responses occur within the required deadline utility § Soft real-time � • systems where deadlines are important but which will still v i v(t) ( t ) benefit utility loss function correctly if deadlines are occasionally missed. § Firm real-time � • systems which are soft real-time but in which there is no r d time i i penalty benefit from late delivery of service ������������ �������� § A single system may have all hard, soft and firm real-time subsystems. TDDI04, K. Arvidsson, IDA, Linköpings universitet. TDDI04, K. Arvidsson, IDA, Linköpings universitet. RT.7 RT.8 Utility function (cont.) Soft Real-Time § Multiple requirements Soft real-time systems: • Deadlines can be missed occasionally , utility typically with an upper limit of misses within a defined Decay rate interval, e.g., a constraint on the maximum number of Linear consecutive deadline misses Exponential • Service can occasionally be delivered late, r d d + time i i i with an upper bound on tardiness, i.e., a.k.o. deadline tolerance. - p § ”Hard real-time is hard, but soft real-time is harder!” - infinity TDDI04, K. Arvidsson, IDA, Linköpings universitet. RT.9 TDDI04, K. Arvidsson, IDA, Linköpings universitet. RT.10 Real-Time Computer Characteristics of a RTS Interacting with Its Environment § Extreme reliability and safety Real-Time Algorithms for Engineering • RTS typically control the environment in which they operate. Interface Clock Digital Control System • Failure to control can result in loss of life, damage to environment or �������� ����� economic loss. ����������������������� ����������� ����� Remote Data Logging § Guaranteed response times Monitoring System • We need to be able to predict with confidence the worst case response times for systems Database > In RTS, performance guarantees are: Data Retrieval Display and Display Devices � Task- and/or class centric sporadic tasks (no period, but � Often ensured a priori relative deadline) ��������� ����� ������������ > In conventional systems, performance is: �������������������� Operator Operator’s � system oriented and often throughput oriented Interface Console � post-processing ( � wait and see � ) Real-Time Computer TDDI04, K. Arvidsson, IDA, Linköpings universitet. RT.11 TDDI04, K. Arvidsson, IDA, Linköpings universitet. RT.12 2

  3. RTS Workload Characteristics Towards Real-Time Scheduling § Tasks are preemptable, independent with arbitrary arrival Non-Realtime-Scheduling (as covered earlier) times § Primary Goal: maximize performance § Tasks have deadlines ( D ) and known computation times ( C ) § Secondary Goal: ensure fairness § Tasks execute on a uni-processor system § Typical metrics: � ����� �����! • minimize response time C • maximize throughput D 1 T1 1 • e.g., FCFS (First-Come-First-Served), C D 2 T2 2 RR (Round-Robin) C D 3 T3 3 C D 4 4 T4 TDDI04, K. Arvidsson, IDA, Linköpings universitet. TDDI04, K. Arvidsson, IDA, Linköpings universitet. RT.13 RT.14 Example: Example: Round-Robin Scheduling Non-preemptive FCFS Scheduling Missed Missed deadline!! deadline!! T1 T1 T2 T2 T3 T3 T4 T4 TDDI04, K. Arvidsson, IDA, Linköpings universitet. RT.15 TDDI04, K. Arvidsson, IDA, Linköpings universitet. RT.16 Spectrum of Scheduling Problems Real-Time Scheduling and Scheduling Algorithms § Primary goal: ensure predictability § Uni-processor / multiprocessor / distributed system § Secondary goal: ensure predictability § Periodic / sporadic / aperiodic tasks § Typical metrics: § Independent / interdependent tasks • guarantee miss ratio = 0 (hard real-time) § Preemptive / non-preemptive • guarantee Prob(missed deadline) < X % (firm real-time) § Static (at system build time) / dynamic (at run time) • maximize completion ratio / minimize miss ratio (firm real-time) § Off-line (all tasks initially given) / on-line (don’t know future) • minimize overall tardiness ; maximize overall usefulness § Handle transient overloads (soft real-time) § Support fault tolerance § e.g., EDF (Earliest Deadline First, LS (Least Slack), RMS (Rate-Monotonic Scheduling) § Easier vs. More difficult § Heuristic (no guarantees) § Recall: Real-time is about enforcing predictability, vs. Approximation (result provably within X % of opt.) and does not equal fast computing!!! vs. Provably optimal TDDI04, K. Arvidsson, IDA, Linköpings universitet. RT.17 TDDI04, K. Arvidsson, IDA, Linköpings universitet. RT.18 3

Recommend


More recommend