6/17/2011. Real-time Operating Systems

Size: px

Start display at page:

Download "6/17/2011. Real-time Operating Systems"

Gordon Nelson
5 years ago
Views:

1 1 1

2 Real-time Operating Systems 2 2

3 Real-time Operating Systems 3 3

4 What is an RTOS Provides efficient mechanisms and services for real-time scheduling and resource management Must keep its own time and resource consumption predictable and accountable Used in the following areas such as: Embedded Systems or Industrial Control Systems Parallel and Distributed Systems E.g. LynxOS, VxWorks, psos, Spring, ARTS, Maruti, MARS 4 4

5 Requirement: Real-time Capability Many embedded systems are real-time (RT) systems and, hence, the OS used in these systems must be real-time operating systems (RTOSes). 5 5

6 Three Requirements of RTOS 1. Timing behavior of the OS must be predictable All services of the OS: upper bound on the execution time guaranteed Get me 4MB of free memory? Scheduling must be deterministic: Unlike standard Java with nondeterministic thread scheduling and garbage collection Short times during which interrupts are disabled Avoid unpredictable delays in critical events Contiguous files to avoid unpredictable head movements 6 6

7 Three Requirements of RTOS 2. 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, e.g., distinguish between original and subsequent errors 7 7

8 Time Services Time plays a central role in real-time systems. Actual time is described by real numbers. Two standards are used in real-time equipment: International Atomic Time (TAI) (french: temps atomic internationale) Free of any artificial artifacts. Universal Time Coordinated (UTC) Defined by astronomical standards UTC and TAI were identical on Jan. 1st, In the meantime, 30 seconds had to be added. 8 8

9 Internal Synchronization Synchronization with one master clock Typically used in startup-phases Distributed synchronization: Collect information from neighbors Compute correction value Set correction value. Precision of step 1 depends on how information is collected: Application level: ~500 µs to 5 ms Operation system kernel: 10 µs to 100 µs Communication hardware: < 10 µs 9 9

10 External Synchronization External synchronization guarantees consistency with actual physical time. Recent trend is to use GPS for external synchronization GPS offers TAI and UTC time information. Resolution is about 100 ns

11 Problems with External Synchronization Fault tolerance: erroneous values are copied to all stations Accepting only small changes to local time. Many time formats too restricted; e.g.: NTP protocol includes only years up to

12 Three Requirements of RTOS 3. The OS must be fast Practically important

13 RTOS has to... 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 13 13

14 Embedded OS: konfigurabilnost No single RTOS will fit all needs, no overhead for unused 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 systems with a large number of derived OSs: Each derived OS must be tested thoroughly; 14 14

15 Interrupt Service Routines Most interrupt routines: Copy peripheral data into a buffer Indicate to other code that data has arrived Acknowledge the interrupt (tell hardware) Longer reaction to interrupt performed outside interrupt routine E.g., causes a process to start or resume running 16 15

16 Handling an Interrupt 1. Normal program execution 2. Interrupt occurs 3. Processor state saved 4. Interrupt routine runs 7. Normal program execution resumes 6. Processor state restored 5. Interrupt routine terminates 17 16

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

18 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 23 18

19 Scheduling Algorithms in RTOS Clock Driven Scheduling Weighted Round Robin Scheduling Priority Scheduling (Greedy / List / Event Driven) 24 19

20 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

21 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

22 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

23 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 28 23

24 Priority-based Preemptive Scheduling Always run the highest-priority runnable process

25 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 30 25

26 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 31 26

27 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 32 27

28 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 33 28

29 Priority Inversion Lower-priority process effectively blocks a higherpriority one Lower-priority process s ownership of lock prevents higher-priority process from running Nasty: makes high-priority process runtime unpredictable 34 29

30 Nastier Example Higher priority process blocked indefinitely Process 2 delays process 3 s release of lock 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 35 30

31 Inverzija prioriteta 36 31

32 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 37 32

33 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 38 33

34 Solutions for Priority Inversion 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 39 34

35 Other views of 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 40 35

36 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) (lowest) 41 36

37 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 42 37

38 When Is There an RMS Schedule? Key metric is processor utilization: sum of compute time divided by period for each process: U = Σ c i / p i 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) 43 38

39 When Is There an RMS Schedule? Asymptotic result: If the required processor utilization is under 69%, RMS will give a valid schedule Converse is not true. Instead: If the required processor utilization is over 69%, RMS might still give a valid schedule, but there is no guarantee 44 39

40 EDF Scheduling RMS assumes fixed priorities Can you do better with dynamically-chosen priorities? Earliest Deadline First: Processes with soonest deadline given highest priority 45 40

41 EDF Meeting a Deadline p1 = (10,20,20) p2 = (15,30,30) utilization is 100% 1 2 P2 takes priority because its deadline is sooner 46 41

42 Key EDF Result Earliest deadline first scheduling is optimal: If a dynamic priority schedule exists, EDF will produce a feasible schedule. Earliest deadline first scheduling is efficient: A dynamic priority schedule exists if and only if utilization is no greater than 100%

43 Static Scheduling More Prevalent RMA only guarantees feasibility at 69% utilization, EDF guarantees it at 100%. EDF is complicated enough to have unacceptable overhead. More complicated than RMA: harder to analyze. Less predictable: can t guarantee which process runs when

44 Summary Cyclic executive Way to avoid an RTOS Adding interrupts helps somewhat Interrupt handlers Gather data, acknowledge interrupt as quickly as possible Cooperative multitasking But programs don t like to cooperate 49 44

45 Summary Preemptive Priority-Based Multitasking Deadlines, not fairness, the goal of RTOSes Rate-monotonic analysis Shorter periods get higher priorities Guaranteed at 69% utilization, may work higher Earliest deadline first scheduling Dynamic priority scheme Optimal, guaranteed when utilization 100% or less 50 45

46 Summary Priority Inversion Low-priority process acquires lock, blocks higher-priority process Priority inheritance temporarily raises process priority Difficult to analyze 51 46

47 TYPES of RTOS Commercial RTOS e.g., VxWorks (Wind River Systems), LynxOS (Lynux Works) Real-time flavor to commercial OS e.g., RT-Linux, KURT (Univ Kansas) Research kernels e.g., HARTS (UMich), Spring (UMass) 52 47

48 Lynx OS Microkernel design Means the kernel footprint is small Only 28 kilobytes in size The small kernel provides essential services in scheduling, interrupt dispatching and synchronization The other services are provided by kernel lightweight service modules, called Kernel Plug-Ins (KPIs) 53 48

49 Lynx Os (contd..) New KPIs can be added to the microkernel and can be configured to support I/O, file systems, TCP/IP, streams and sockets Here KPIs are multi-threaded, which means each KPI can create as many thread as it wants 54 49

50 Lynx OS (contd..) Lynx OS is a self hosted system wherein development can be done in the same system In such a system, there is a need for protecting the OS from such huge memory consuming applications (compilers, debuggers) LynxOS offers memory protection through hardware MMUs 56 50

51 Lynx OS (contd..) Applications make I/O requests to I/O system through system calls Kernel directs I/O request to the device driver Each device driver has an interrupt handler and kernel thread 57 51

52 VxWorks Monolithic Kernel Leads to an improved performance with less runtime overhead However the scalability is poor I.e. the footprint of the kernel is affected a little. Provides interfaces specified by RT-POSIX standards in addition to its own APIs Though not a multiprocessor OS, provides sharedmemory objects: shared binary and counting semaphores 59 52

53 VxWorks (contd..) Reduced Context Switch time Saves only those register windows that are actually in use (on a Sparc) When a task s context is restored, only the relevant register window is restored To increase response time, it saves the register windows in a register cache useful for recurring tasks 61 53

54 ARTS - Distributed OS Distributed real-time OS provides a predictable distributed real-time computing environment 62 54

55 ARTS (Contd..) Distributed computing environment Heterogeneous computing environment Need for global view of the system and resources No over-utilization and under-utilization of a particular system in a distributed system Guaranteeing predictability in such a system is difficult than in multiprocessor system case How to synchronize the clocks in a distributed system? 63 55

56 ARTS (contd..) Scheduling Integrated time-driven scheduler ITDS scheduler provides an interface between the scheduling policies and the rest of the operating system Allows different scheduling policies to exist (though only one can be used at a time) Communication scheduling Extended RMS for communication scheduling integrating message and processor scheduling 64 56

57 and also: AMX (KADAK) C Executive (JMI Software) RTX (CMX Systems) ecos (Red Hat) INTEGRITY (Green Hills Software) LynxOS (LynuxWorks) µc/os-ii (Micrium) Nucleus... (Mentor Graphics) RTOS-32 (OnTime Software) OS-9 (Microware) OSE (OSE Systems) psosystem (Wind River) QNX (QNX Software Systems) Quadros (RTXC) RTEMS (OAR) ThreadX (Express Logic) Linux/RT (TimeSys) VRTX (Mentor Graphics) VxWorks (Wind River) 65 57

58 How to Choose a Real-Time Operating System Selection process Considering the cost of engineering time these days, a few thousand dollars is a bargain for a commercial RTOS. A wide variety of operating systems are available to suit most projects and pocketbooks. Commercial operating systems form a continuum of functionality, performance, and price. Those at the lower end of the spectrum offer just a basic preemptive scheduler and a few other key system calls. These operating systems are usually inexpensive, come with source code that you can modify, and do not require payment of any royalties

59 How to Choose a Real-Time Operating System Operating systems at the other end of the spectrum typically include a lot of functionality beyond the basic scheduler. These operating systems can be quite expensive, though, with startup costs ranging from $10,000 to $50,000 and royalties due on every copy shipped in ROM. However, this price often includes free technical support and training and a set of integrated development tools

60 How to Choose a Real-Time Operating System The best reason to choose a commercial operating system is the advantage of using something that is better tested and, therefore, more reliable than a kernel you have developed inhouse. So one of the most important things you should be looking for from your OS vendor is experience

61 69 61

62 75 62

What s an Operating System? Real-Time Operating Systems. Cyclic Executive. Do I Need One? Handling an Interrupt. Interrupts

What s an Operating System? Real-Time Operating Systems Provides environment for executing programs Prof. Stephen A. Edwards Process abstraction for multitasking/concurrency Scheduling Hardware abstraction