Real-Time Operating Systems Lecture for the Embedded …hy428/reading/rtos-may22-2014.pdf ·...
Transcript of Real-Time Operating Systems Lecture for the Embedded …hy428/reading/rtos-may22-2014.pdf ·...
Institute of Computer Science (ICS)
Foundation for Research and Technology – Hellas (FORTH)
� Manolis Marazakis ([email protected])
Real-Time Operating Systems
Lecture for the Embedded Systems Course
CSD, University of Crete (May 23, 2014)
Real-Time OS = ?� Real-Time
� Control External Events
� Synchronous, Asynchronous, Independent
� Speed
� Fast response, Low overheads
� Deterministic
� A late answer is a wrong answer
� Multi-Tasking
� Sequence: One task controlling all events in an infinite loop
� Multi-tasking: Task “Waiting” on Event, Task becomes “Ready” upon Event
� Priority Scheduling
� Preemptive Scheduling on Task Priority
� No delay on Context Switch to the next Tick
� Equal Priority tasks won’t preempt each other
� Scheduling due to synchronous or asynchronous event
� Round-Robin Scheduling
� All tasks in the same priority share the CPU
� Context Switch in each (predefined) time slice period
2 Real-Time Operating Systems
Need for Synchronization ?
� Reentrancy & Shared Resources
� Co-ordination between tasks
� Asynchronous events
� Interrupts & Exceptions
� Interrupts allow devices to notify the CPU on events
� Interrupt Levels
� Exceptions
� Unplanned event generated by the CPU (e.g. divide-by-0)
� Exceptions will generate an “internal” interrupt
� ISR (Interrupt Service Routines)
� Not a task (has no “task control block”)
� Timers
� Synchronous events
3 Real-Time Operating Systems
RTOS vs General-Purpose OS
� General-purpose OS:
� Key criteria: Task throughput, fairness
� “average case” optimizations
� Real-Time OS:
� Deterministic timing behavior
� “worst-case” guarantees
� Processing must be done within a time constraint or the system will fail.
� All delays in the system will be bounded; from the retrieval of stored
data to the time RTOS finishes the request.
4 Real-Time Operating Systems
Can Linux provide real-time guarantees ? (NO)
� (usually) Non-preemptive kernel � A system call may sometimes take a “long time” to complete
� Coarse timer resolution� Tasks can be released with millisecond precision (1/10/100)
� Virtual memory� Unpredictable delay
� Variable task priority� Task priority varies with time, to achieve fairness
� Batching and possible re-ordering of storage & network operations (for efficient use of H/W)
� High-priority task may queue behind a low-priority task that has issued a system call
� High-priority tasks may have to wait for lower priority tasks to release resources
5 Real-Time Operating Systems
Can Linux provide real-time guarantees ? (YES)
� Provides RT-POSIX interface
� Fixed priority real-time scheduling classes
� SCHED_FIFO
� SCHED_RR
� Timesharing in SCHED_OTHER
� Preemptive Linux kernel …
6 Real-Time Operating Systems
Concerns: • Real-time ?
• Footprint ?
Outline
� RTOS “theory”
� LynxOS
� QNX
� Wind River VxWorks
� RTLinux
� TimeSys Linux
7 Real-Time Operating Systems
POSIX 1003.1b standard
•Asynchronous I/O
• Semaphores
• Message queues
• Queued signals
• Scheduling
• Clocks &timers
• Memory Management
� Kernel = ?
� Process Management
� Memory Management
� I/O System Management
� Three models of “kernel” :
� Monolithic
� Layered
� Microkernel (client-server)
Three Models of Kernel
Real-Time Operating Systems8
� In a monolithic-modularized OS, the functionality is
integrated into a single executable file that is made up of
modules, separate pieces of code reflecting various OS
functionality.
Monolithic Kernel
Real-Time Operating Systems9
� In the layered design, the OS is divided into hierarchical layers
(0...N), where upper layers are dependent on the functionality
provided by the lower layers (via APIs).
� Like the monolithic design, layered OSes are a single large file that
includes device drivers and middleware
Layered Kernel
Real-Time Operating Systems10
� An OS that is stripped down to minimal functionality,
commonly only process and memory management subunits
is called a client-server OS, or a microkernel.
� The remaining functionality typical of other kernel algorithms is
abstracted out of the kernel, while device drivers, for instance,
are usually abstracted out of a microkernel entirely
Microkernel (Client-server) OS
Real-Time Operating Systems11
� Tasks are given control of the master CPU until they have finished execution, regardless of the length of time or the importance of the other tasks that are waiting.
� First-Come-First-Serve (FCFS)/ Run-To-Completion
� The response time of a FCFS algorithm is typically slower than other algorithms
� Shortest Process Next (SPN)/Run-To-Completion
� SPN algorithm has faster response times for shorter processes. However, then the longer processes are penalized by having to wait until all the shorter processes in the queue have run. In this scenario, starvation can occur to longer processes if the ready queue is continually filled with shorter processes. The overhead is higher than that of FCFS, since the calculation and storing of run times for the processes in the ready queue must occur.
� Co-operative: the tasks themselves run until they tell the OS when they can be context switched (i.e., for I/O, etc.).
� This algorithm can be implemented with the FCFS or SPN algorithms, rather than the run-to-completion scenario, but starvation could still occur with SPN if shorter processes were designed not to “cooperate,” for example.
Non-preemptive Scheduling
Real-Time Operating Systems12
� Round Robin/FIFO (First In, First Out) Scheduling
� Each process in the FIFO queue is allocated an equal time slice (the duration
each process has to run). An interrupt is generated at the end of each of
these intervals to start the pre-emption process.
� Priority (Preemptive) Scheduling
� Every process is assigned a priority
� The processes with the highest priority always preempt lower priority
processes when they want to run
� Problems:
� Process starvation, Priority inversion, how to determine the priorities of
various processes, i.e. same priority vs how often the process(es) are run
Preemptive Scheduling
Real-Time Operating Systems13
Preemptive Scheduling (cont.)
� Rate Monotonic Scheduling (RMS) scheme, in which
tasks are assigned a priority based upon how often
they execute within the system.
� EDF (Earliest Deadline First)/Clock Driven Scheduling
� The EDF/Clock Driven algorithm schedules priorities to
processes according to three parameters:
�frequency (number of times process is run)
�deadline (when processes execution needs to be
completed)
�duration (time it takes to execute the process)
14 Real-Time Operating Systems
� Tasks with real-time requirements have to be allowed to
preempt other tasks
� Preemptive scheduling must be one of the algorithms implemented
within RTOS schedulers
� RTOS schedulers also make use of their own array of timers, ultimately based
upon the system clock, to manage and meet their hard deadlines.
� Whether an RTOS or a non real-time OS in terms of scheduling,
all will vary in their implemented scheduling schemes. E.g:
� vxWorks (Wind River) : priority-based + round-robin
� Jbed (Esmertec) : EDF
� Linux (Timesys) : priority-based
Preemptive Scheduling & RTOS
Real-Time Operating Systems15
LynxOS (1/2)
� Microkernel design
� Small kernel footprint : ~28 KB in size
� The microkernel provides essential services in scheduling, interrupt
dispatching and synchronization
� The other services are provided by kernel lightweight service
modules � Kernel Plug-Ins (KPIs)
� New KPIs can be added to the microkernel to support I/O, file
systems, TCP/IP, streams and sockets
� Can function as a multipurpose UNIX OS
� LynxOS offers memory protection through hardware MMUs
� Applications make I/O requests to I/O system through system calls
� Kernel directs I/O request to the device driver
16 Real-Time Operating Systems
LynxOS (2/2)
� Each device driver has an interrupt handler and kernel
thread
� The interrupt handler carries the 1st step of interrupt handling
� If it does not complete the processing, it sets an asynchronous trap
to the kernel
� Later, when kernel can respond to the software interrupt, it
schedules an instance of the kernel thread to complete the
interrupt processing
17 Real-Time Operating Systems
QNX Neutrino (1/2)
� Microkernel design – kernel provides essential threads and real-time services� Microkernel footprint: ~12 KB
� Other services are considered as resource managers and can be added or removed at run-time
� SMP RTOS – requires high end, networked SMP machines with GBs of physical memory
� Message passing:� Messages are the basic means of inter-process communication among
all threads
� Message-based priority tracking
� Messages are delivered at the priority order and the service provider executes at the priority of the highest priority clients waiting for service
� So, if the highest priority task wants to do read some data from file, the file system resource manager will execute at this task’s priority
18 Real-Time Operating Systems
QNX Neutrino (2/2)
� When a service provider thread wants to provide service,
then it creates a channel (for exchanging messages) with its
service identifier for identification
� To get a service from a provider, the client thread attaches it to
the provider’s channel
� Within the client, this connection is directly mapped to the file
descriptor (so RFS can be sent directly to the file descriptor)
� QNX messages are blocking (unlike POSIX standards)
19 Real-Time Operating Systems
VxWorks (1/4)
� Microkernel � Monolithic Kernel (CoreOS + Wind microkernel)
� Provides interfaces specified by RT-POSIX standards in addition to its own APIs
� Shared-memory objects: shared binary and counting semaphores
� Standard MMU (as in modern OS)
� Provides basic virtual-to-physical memory mapping
� Allows to add new mappings and make portions of memory non cacheable
� When memory boards are added dynamically, to increase the address space
for inter-process communication
� The data is made non cacheable, to ensure cache consistency
20 Real-Time Operating Systems
VxWorks (2/4)
� Reduced Context Switch time
� Saves only those register windows that are actually in use
� (e.g. applicable on SPARC)
� When a task’s context is restored, only the relevant register window is
restored
� To improve response time, it saves the register windows in a register cache
� useful for recurring tasks
21 Real-Time Operating Systems
VxWorks (3/4)
22 Real-Time Operating Systems
22
Real-Time Embedded Application
Graphics Multiprocessing Internet
Java Support POSIX Library File System
WindNet Networking
Wind MicrokernelCore OS:
RTLinux (1/3)
� Patch-set for Linux kernel + RT API
� Runs Linux kernel as lowest-priority task (pre-emptible)
24 Real-Time Operating Systems 24
System libraries
Device drivers Linux kernel
Hardware
I/O Hardware Interrupts
User Processes
RTLinux (2/3)
25 Real-Time Operating Systems 25
Hardware
System libraries
Device drivers Linux kernel
I/O Software Interrupts
User Processes
RTLinux Plug-in
Real Time Tasks
RT-Scheduler
I/O Hardware Interrupts
Linux is executed in the background
Direct
h/w
access
RTLinux (3/3)
� Development flow for RT-application program:
1. Develop RT-application program : Linux kernel module
2. Load RT-Core / RT-Scheduler / RT-FIFOs � transit to RTLinux
3. Load RT-application module
26 Real-Time Operating Systems
Interrupt control H/W
Real-Time Kernel
LinuxReal-Time
Tasks
Linux
Processes
Real-Time
FIFOs
� A Kernel that provides to applications Timely, Guaranteed, and Enforced access
to System Resources
� Allows Applications to specify only their Resource Demands
� … leaving the Kernel to satisfy Demands using hidden management schemes
27 Real-Time Operating Systems
Linux/RK
Reservation
Parameters
“T”: Period (1/f)
“C”: Execution time within period
“D”: Deadline within period
Hardware
Resource
Kernel Linux
KernelKernel
User-Level
LoadableKernelModule
Linux
Process
Linux
Process
Linux
Process
Kernel
Commercialized Linux/RK: TimeSys Linux
Real-Time Operating Systems31
� TimeSys Linux/GPL
� Basic TimeSys Linux kernel
� Full preemption at the kernel level, prioritized interrupt handlers, unlimited priorities, ...
� TimeSys Linux/Real-time
� Support priority inheritance and a POSIX-based high-resolution timer API
� TimeSys Linux/CPU
� Support CPU reservation, which gives a thread, process, or process group exclusive use of the CPU.
� TimeSys Linux/Net
� Support network bandwidth reservation to guarantee that your thread or process will get the bandwidth it requires, regardless of network activity in other processes
� TimeSys Linux GPL: Downloadable from
sourceforge.net/projects/timesysgpl
� Resource kernel and QoS Support
� guaranteed, timely and enforced access to
CPU cycles and network bandwidth
� SMP support with QoS Reservations
� Fully preemptive kernel
� Fixed-priority scheduling (POSIX-compliant)
� High-resolution timer and clock support
(microsecond resolution)
� Periodic processes
� Message queues
� Priority inheritance and priority ceiling protocol
emulation support to avoid unbounded priority
inversion
Sources
� Victor Yodaiken, The RTLinux Manifesto, In Proceedings of the 5th Linux Expo, 1999
� Victor Yodaiken, Cort Dougan, Michael Barabanov, RTLinux/RTCore dual kernel real-time operating system, FSM Labs White Paper, 2004 [ available from http://vyodaiken.com/papers-and-talks/ ]
� QNX Neutrino RTOS System Architecture [ available from qnx.com/download/ ]
� http://www.lynx.com/products/real-time-operating-systems/lynxos-rtos/
� http://www.VxWorks.com/collateral
� Raj Rajkumar, Kanaka Juvva, Anastasio Molano and Shui Oikawa, Resource Kernels: A Resource-Centric Approach to Real-Time Systems, In Proceedings of the SPIE/ACM Conference on Multimedia Computing and Networking, January 1998.
32 Real-Time Operating Systems