Upload
others
View
2
Download
0
Embed Size (px)
Citation preview
6/17/2011
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
4
• 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
6/17/2011
5
Requirement: Real-time Capability
• Many embedded systems are real-time (RT)
systems and, hence, the OS used in these
5
systems and, hence, the OS used in these
systems must be real-time operating systems
(RTOSes).
6/17/2011
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:
6
• 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/17/2011
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
7
– OS must provide precise time services with high
resolution, e.g., distinguish between original and
subsequent errors
6/17/2011
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)
8
(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, 1958.
– In the meantime, 30 seconds had to be added.
6/17/2011
9
Internal Synchronization
• Synchronization with one master clock
– Typically used in startup-phases
• Distributed synchronization:
– Collect information from neighbors
– Compute correction value
9
– 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
6/17/2011
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.
10
• GPS offers TAI and UTC time information.
– Resolution is about 100 ns.
6/17/2011
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;
11
• Many time formats too restricted;
e.g.: NTP protocol includes only years up to 2036
6/17/2011
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.
13
• a system of priority inheritance has to exist.
• OS Behaviour should be known
6/17/2011
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.
14
– 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;
6/17/2011
15
Interrupt Service Routines
Most interrupt routines:
• Copy peripheral data into a buffer
• Indicate to other code that data has arrived
16
• 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
6/17/2011
16
Handling an Interrupt
1. Normal program execution
2. Interrupt occurs
3. Processor state saved 4. Interrupt routine
runs
17
5. Interrupt routine terminates
6. Processor state restored
7. Normal program execution resumes
6/17/2011
17
Typical RTOS Task Model
• Each task a triplet: (execution time, period, deadline)
• Usually, deadline = period
• Can be initiated any time during the period
22
Execution time
Period
Deadline
Time
Initiation
6/17/2011
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
23
is due in an hour, you work on that one
• Fairness does not help you meet deadlines
6/17/2011
19
Scheduling Algorithms in RTOS
• Clock Driven Scheduling
• Weighted Round Robin Scheduling
24
• Priority Scheduling
(Greedy / List / Event Driven)
6/17/2011
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.
25
regular time instances.
• Minimal runtime overhead.
• Not suitable for many applications.
6/17/2011
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
26
• 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.
6/17/2011
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
27
• 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.
6/17/2011
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
28
ready to run
• Process runs to completion unless preempted
6/17/2011
24
Priority-based Preemptive Scheduling
• Always run the highest-priority runnable process
1
2
3
29
3
6/17/2011
25
Priority Scheduling
• Processor never left idle when there are ready tasks
• Processor allocated to processes according to priorities
• Priorities
– static - at design time
30
static - at design time
– Dynamic - at runtime
6/17/2011
26
Priority Scheduling
• Earliest Deadline First (EDF)
– Process with earliest deadline given highest priority
• Least Slack Time First (LSF)
– slack = relative deadline – execution left
31
– slack = relative deadline – execution left
• Rate Monotonic Scheduling (RMS)
– For periodic tasks
– Tasks priority inversely proportional to it’s period
6/17/2011
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
32
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
6/17/2011
28
Priority Inversion
• RMS and EDF assume no process interaction
• Often a gross oversimplification
• Consider the following scenario:
1
33
1
2
Process 2 begins running
Process 2 acquires lock on resource
Process 1 preempts Process 2
Process 1 tries to acquire lock for resource
6/17/2011
29
Priority Inversion
• Lower-priority process effectively blocks a higher-
priority one
• Lower-priority process’s ownership of lock prevents
higher-priority process from running
34
higher-priority process from running
• Nasty: makes high-priority process runtime
unpredictable
6/17/2011
30
Nastier Example
• Higher priority process blocked indefinitely
1
2
Process 2 delays process 3’s release of lock
35
Process 3 begins running
Process 3 acquires lock on resource
Process 2 preempts Process 3
Process 1 tries to acquire lock and is blocked
3
2
Process 1 preempts Process 2
6/17/2011
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
37
• 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
6/17/2011
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
38
to analyze
• RMS gives a strong result
• No equivalent result when locks and priority
inheritance is used
6/17/2011
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
39
– 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
6/17/2011
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
40
small
– Should fit in ROM
• Sophisticated features can be removed
– No Virtual Memory
– No Protection
6/17/2011
36
Rate-Monotonic Scheduling
• Common way to assign priorities
• Simple to understand and implement:
Processes with shorter period
given higher priority
41
• E.g.,
given higher priority
Period Priority
10 1 (highest)
12 2
15 3
20 4 (lowest)
6/17/2011
37
RMS Missing a Deadline
• p1 = (10,20,20) p2 = (15,30,30) utilization is 100%
1
2
42
2
P2 misses first deadline
Would have met the deadline if p2 =
(10,30,30), utilization reduced 83%
6/17/2011
38
When Is There an RMS Schedule?
• Key metric is processor utilization: sum of compute
time divided by period for each process:
U = Σ ci/ p
i
• No schedule can possibly exist if U > 1
43
• 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)
6/17/2011
39
When Is There an RMS Schedule?
• Asymptotic result:
If the required processor utilization is under
69%, RMS will give a valid schedule
44
• 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
6/17/2011
40
EDF Scheduling
• RMS assumes fixed priorities
• Can you do better with dynamically-chosen
priorities?
45
• Earliest Deadline First:
Processes with soonest deadline given highest
priority
6/17/2011
41
EDF Meeting a Deadline
• p1 = (10,20,20) p2 = (15,30,30) utilization is 100%
1
2
46
2
P2 takes priority because its deadline is
sooner
6/17/2011
42
Key EDF Result
• Earliest deadline first scheduling is optimal:
If a dynamic priority schedule exists,
EDF will produce a feasible schedule.
47
• Earliest deadline first scheduling is efficient:
A dynamic priority schedule exists if
and only if utilization is no greater than
100%.
6/17/2011
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.
48
overhead.
• More complicated than RMA: harder to analyze.
• Less predictable: can’t guarantee which process runs
when.
6/17/2011
44
Summary
• Cyclic executive
– Way to avoid an RTOS
– Adding interrupts helps somewhat
• Interrupt handlers
49
• Interrupt handlers
– Gather data, acknowledge interrupt as quickly as possible
• Cooperative multitasking
– But programs don’t like to cooperate
6/17/2011
45
Summary
• Preemptive Priority-Based Multitasking
– Deadlines, not fairness, the goal of RTOSes
• Rate-monotonic analysis
– Shorter periods get higher priorities
50
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
6/17/2011
46
Summary
• Priority Inversion
– Low-priority process acquires lock, blocks higher-priority
process
– Priority inheritance temporarily raises process priority
51
– Difficult to analyze
6/17/2011
47
TYPES of RTOS
• Commercial RTOS
– e.g., VxWorks (Wind River Systems), LynxOS (Lynux Works)
• Real-time flavor to commercial OS
52
• Real-time flavor to commercial OS
– e.g., RT-Linux, KURT (Univ Kansas)
• Research kernels
– e.g., HARTS (UMich), Spring (UMass)
6/17/2011
48
Lynx OS
• Microkernel design
– Means the kernel footprint is small
– Only 28 kilobytes in size
• The small kernel provides essential services in
53
• 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)
6/17/2011
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
54
• Here KPIs are multi-threaded, which means
each KPI can create as many thread as it wants
6/17/2011
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
56
the OS from such huge memory consuming applications (compilers, debuggers)
• LynxOS offers memory protection through hardware MMUs
6/17/2011
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
57
• Each device driver has an interrupt handler
and kernel thread
6/17/2011
52
VxWorks
• Monolithic Kernel
– Leads to an improved performance with less run-time overhead
– However the scalability is poor I.e. the footprint of the kernel is affected a little.
59
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 shared-
memory objects: shared binary and counting
semaphores
6/17/2011
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
61
– 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
6/17/2011
54
ARTS - Distributed OS
• Distributed real-time OS – provides a
predictable distributed real-time computing
environment
62
6/17/2011
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
63
– 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?
6/17/2011
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
64
– 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
6/17/2011
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)
65
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)
6/17/2011
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
66
• 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.
6/17/2011
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
67
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.
6/17/2011
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,
68
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.