Operacijski sistemi za delo v realnem času

1. Operacijski sistemi za delo v realnem času

2. Sistemi za delo v realnem času • A system is said to be Real Time if it is required to complete it’s work & deliver it’s services on time. • Example – Flight Control System • All tasks in that system must execute on time. • Non Example – PC system

3. Mehki in trdi sistemi za delo v realnem času • Hard Real Time System • Failure to meet deadlines is fatal • example : Flight Control System • Soft Real Time System • Late completion of jobs is undesirable but not fatal. • System performance degrades as more & more jobs miss deadlines • Online Databases • Qualitative Definition.

4. Mehki in trdi sistemi za delo v realnem času • Hard Real Time System • Validation by provably correct procedures or extensive simulation that the system always meets the timings constraints • Soft Real Time System • Demonstration of jobs meeting some statistical constraints suffices. • Example – Multimedia System • 25 frames per second on an average

5. Example: Fly-by-wire Avionics • Hard real-time system with multirate behavior Control laws Actuating Actuators Signal Conditioning Sensors Aileron 1 1 kHz Aileron gyros, accel. INU 1kHz Pitch control 500 Hz Aileron 2 1 kHz Aileron GPS 20 Hz GPS Lateral Control 250 Hz Air data 1 kHz Elevator 1 kHz Elevator Sensor Throttle Control 250 Hz Joystick 500 Hz Stick Rudder 1 kHz Rudder

6. Peripheral devices and protocols • Interfacing • Serial/parallel ports, USB, I2C, PCMCIA, IDE • Communication • Serial, Ethernet, Low bandwidth radio, IrDA, • 802.11b based devices • User Interface • LCD, Keyboard, Touch sensors, Sound, Digital • pads, Webcams • Sensors • A variety of sensors using fire, temperature, • pressure, water level, seismic, sound, vision

7. Trdi RTOS… • Thread priorities can be set by the client • Threads always run according to priority • Kernel must be preemptible or bounded • Interrupts must be bounded • No virtual memory

8. Mehki RTOS… • Like a hard RTOS: • Priority scheduling, with no degradation • Low dispatch latency • Preemptible system calls • No virtual memory (or allow pages to be locked) • Linux: guarantees about relative timing of tasks, no guarantees about syscalls

9. Vloga OS v sistemih realnega časa • Standalone Applications • Often no OS involved • Micro controller based Embedded Systems • Some Real Time Applications are huge & complex • Multiple threads • Complicated Synchronization Requirements • Filesystem / Network / Windowing support • OS primitives reduce the software design time

10. Ali za RT potrebujem operacijski sistem? • Ne vedno • Preprost pristop: cikličen izvajalnik loop do part of task 1 do part of task 2 do part of task 3 end loop

11. Cikličen izvajalnik • Prednosti • Preprosta implementacija • Nizek "overhead" • Visoka predvidljivost • Slabosti • Se ne more odzivati na sporadične dogodke • Vse se izvaja v zanki • Kodo razvrščamo ročno

12. Prekinitve • Nekateri dogodki ne morajo čakati na naslednjo iteracijo zanke • Komunikacijski kanali • Prehodni dogodki • Rešitev: Cilkičen izvajalnik + prekinitvene rutine

13. Ciklični izvajalnik + prekinitve • Primeren za aplikacije za procesiranje signalov • Cenen, predvidljiv rokovalnik prekinitev: • When interrupt occurs, execute a single user-specified instruction • This typically copies peripheral data into a circular buffer • No context switch, no environment save, no delay • Slabosti • Main loop still running in lockstep • Programmer responsible for scheduling • Scheduling static • Sporadic events handled slowly

14. Cooperative Multitasking • A cheap alternative • Non-preemptive • Processes responsible for relinquishing control • Examples: Original Windows, Macintosh • A process had to periodically call get_next_event() to let other processes proceed • Drawbacks: • Programmer had to ensure this was called frequently • An errant program would lock up the whole system • Alternative: preemptive multitasking

15. Konkurenčnost zagotavlja OS • Basic philosophy: • Scheduling and function usually orthogonal • Changing the algorithm would require a change in scheduling Let the operating system handle scheduling, and let the programmer handle function

16. Značilnosti RTOS • Razvrščanje. • alokacija resursov. • Rokovanje prekinitev. • Velikost jedra itd.

17. Inter Process Communication • Primary ones: Shared Memory, Pipes, sockets, message queues • Important characteristics to be taken care of: • Non-blocking communication • Bounded latency • Asynchronous communication

18. Memory Management • Most RTOS allow restricted use of dynamic memory allocation- in soft RT systems - to avoid garbage collection. • Providing support for Virtual Memory is a big decision to make. • Movement of data between disk and RAM is a slow process. How slow?? Leads to non-determinism • Not providing VM, means not using MMU in processor. • VM provided with minimum capabilities, Process “Locked” in memory and hence no swapping has to be done- could be used for soft real-time.

19. Comparison of some RTOS

20. Obvezne zahteve za RTOS  • an RTOS has to be multithreaded and preemptible. • the notion of thread priority has to exist. • the OS has to support predictable thread synchronisation mechanisms  • a system of priority inheritance has to exist. • OS Behaviour should be known

21. Vgrajeni OS: Zahteva:konfigurabilnost • No single RTOS will fit all needs, no overhead forunused functions tolerated  configurability needed. • simplest form: remove unused functions (by linker ?). • Conditional compilation (using #if and #ifdef commands). • Dynamic data might be replaced by static data. • Advanced compile-time evaluation useful. • Object-orientation could lead to a derivation subclasses. • Verification a potential problem of systemswith a large number of derived OSs: • Each derived OS must be tested thoroughly;

22. Embedded OS Standard OS kernel Vgrajeni OS:zahteva:Disk in omrežje naj upravljajo posli(tasks) • Disc & network handled by tasks instead of integrated drivers. Relatively slow discs & networks can be handled by tasks. • Many ES without disc, a keyboard, a screen or a mouse. • Effectively no device that needs to be supported by all versions of the OS, except maybe the system timer.

23. Privileged I/O instructions not necessary andtasks can do their own I/O. • Example: Let switch be the address of some switchSimply use • load register,switchinstead of OS call. Vgrajeni OS: opcija: zaščita • Protection mechanisms not always necessary:ES typically designed for a single purpose,untested programs rarely loaded, SW considered reliable.(However, protection mechanisms may be needed for safety and security reasons).

24. Vgrajeni OS:zahteva: prekinitve niso omejene na OS • Interrupts can be employed by any processFor standard OS: serious source of unreliability.Since • embedded programs can be considered to be tested, • since protection is not necessary and • since efficient control over a variety of devices is required, • it is possible to let interrupts directly start or stop tasks (by storing the tasks start address in the interrupt table). • More efficient than going through OS services. • Reduced composability: if a task is connected to an interrupt, it may be difficult to add another task which also needs to be started by an event.

25. Vgrajeni OS:zahteva zmožnost realnega časa • Many embedded systems are real-time (RT) systems and, hence, the OS used in these systems must be real-time operating systems (RTOSes).

26. Operacijski sistemi za delo v realnem času: RTOS • Def.: (A) real-time operating system is an operating system that supports the construction of real-time systems • Ključne zahteve so: • The timing behavior of the OS must be predictable. services of the OS: Upper bound on the execution time!RTOSs must be deterministic: • unlike standard Java, • short times during which interrupts are disabled, • contiguous files to avoid unpredictable head movements.

27. Operacijski sistemi za delo v realnem času: RTOS • OS must manage the timing and scheduling • OS possibly has to be aware of task deadlines;(unless scheduling is done off-line). • OS must provide precise time services with high resolution.

28. Razvrščanje v RTOS • More information about the tasks are known • No of tasks • Resource Requirements • Release Time • Execution time • Deadlines • Being a more deterministic system better scheduling algorithms can be devised.

29. Typical RTOS Task Model • Each task a triplet: (execution time, period, deadline) • Usually, deadline = period • Can be initiated any time during the period Execution time Deadline Initiation Time Period

30. Real-Time Is Not Fair • Main goal of an RTOS scheduler: meeting deadlines • If you have five homework assignments and only one is due in an hour, you work on that one • Fairness does not help you meet deadlines

31. Algoritmi razvrščanja pri RTOS • Clock Driven Scheduling • Weighted Round Robin Scheduling • Priority Scheduling (Greedy / List / Event Driven)

32. Clock Driven scheduling • All parameters about jobs (release time/ execution time/deadline) known in advance. • Schedule can be computed offline or at some regular time instances. • Minimal runtime overhead. • Not suitable for many applications.

33. Weighted Round-Robin Approach • Different jobs given different weights • weight is fraction of processor time allocated to job • Size of time slice given to job depends on weight • Proposed for scheduling real-time traffic in high-speed switched networks built on round-robin scheme.

34. Weighted Round Robin • Jobs scheduled in FIFO manner • Time quantum given to jobs is proportional to it’s weight • Example use : High speed switching network • QOS guarantee. • Not suitable for precedence constrained jobs. • Job A can run only after Job B. No point in giving time quantum to Job B before Job A.

35. Priority-based Scheduling • Typical RTOS based on fixed-priority preemptive scheduler • Assign each process a priority • At any time, scheduler runs highest priority process ready to run • Process runs to completion unless preempted

36. Priority-based Preemptive Scheduling • Always run the highest-priority runnable process 1 2 3

37. Priority Scheduling • Processor never left idle when there are ready tasks • Processor allocated to processes according to priorities • Priorities • static - at design time • Dynamic - at runtime

38. Priority Scheduling • Earliest Deadline First (EDF) • Process with earliest deadline given highest priority • Least Slack Time First (LSF) • slack = relative deadline – execution left • Rate Monotonic Scheduling (RMS) • For periodic tasks • Tasks priority inversely proportional to it’s period

39. Priority-Based Preempting Scheduling • Multiple processes at the same priority level? • A few solutions • Simply prohibit: Each process has unique priority • Time-slice processes at the same priority • Extra context-switch overhead • No starvation dangers at that level • Processes at the same priority never preempt the other • More efficient • Still meets deadlines if possible

40. Priority Inversion • RMS and EDF assume no process interaction • Often a gross oversimplification • Consider the following scenario: 1 2 Process 1 tries to acquire lock for resource Process 1 preempts Process 2 Process 2 acquires lock on resource Process 2 begins running

41. Priority Inversion • Lower-priority process effectively blocks a higher-priority one • Lower-priority process’s ownership of lock prevents higher-priority process from running • Nasty: makes high-priority process runtime unpredictable

42. Nastier Example • Higher priority process blocked indefinitely Process 2 delays process 3’s release of lock 1 2 3 Process 1 tries to acquire lock and is blocked Process 1 preempts Process 2 Process 2 preempts Process 3 Process 3 acquires lock on resource Process 3 begins running

43. Inverzija prioritete

44. Priority Inheritance • Solution to priority inversion • Temporarily increase process’s priority when it acquires a lock • Level to increase: highest priority of any process that might want to acquire same lock • I.e., high enough to prevent it from being preempted • Danger: Low-priority process acquires lock, gets high priority and hogs the processor • So much for RMS

45. Priority Inheritance • Basic rule: low-priority processes should acquire high-priority locks only briefly • An example of why concurrent systems are so hard to analyze • RMS gives a strong result • No equivalent result when locks and priority inheritance is used

46. Rešitev inverzije prioritete • Non Blocking Critical Section • Higher priority Thread may get blocked by unrelated low priority thread • Priority Ceiling • Each resource has an assigned priority • Priority of thread is the highest of all priorities of the resources it’s holding • Priority Inheritance • The thread holding a resource inherits the priority of the thread blocked on that resource

47. Drugi vidiki RTOS • Interrupt Latency should be very small • Kernel has to respond to real time events • Interrupts should be disabled for minimum possible time • For embedded applications Kernel Size should be small • Should fit in ROM • Sophisticated features can be removed • No Virtual Memory • No Protection

48. Rate-Monotonic Scheduling • Common way to assign priorities • Simple to understand and implement: • E.g., Processes with shorter period given higher priority Period Priority 10 1 (highest) 12 2 15 3 20 4 (lowest)

49. RMS Missing a Deadline • p1 = (10,20,20) p2 = (15,30,30) utilization is 100% 1 2 Would have met the deadline if p2 = (10,30,30), utilization reduced 83% P2 misses first deadline

50. When Is There an RMS Schedule? • Key metric is processor utilization: sum of compute time divided by period for each process: U =  ci / pi • No schedule can possibly exist if U > 1 • No processor can be running 110% of the time • Fundamental result: • RMS schedule always exists if U < n (2 1/n – 1) • Proof based on case analysis (P1 finishes before P2)