62
6/17/2011 1 1

6/17/2011 - leda.elfak.ni.ac.rs

  • Upload
    others

  • View
    2

  • Download
    0

Embed Size (px)

Citation preview

6/17/2011

1

1

6/17/2011

2

Real-time Operating Systems

2

6/17/2011

3

Real-time Operating Systems

3

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

12

Three Requirements of RTOS

3. The OS must be fast

Practically important.

12

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

31

Inverzija prioriteta

36

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.

6/17/2011

61

69

6/17/2011

62

75