1 / 30

Real-Time Operating Systems - QNX

Real-Time Operating Systems - QNX. Brett O’Neill CSE 8343 – Group A6. Overview. Real-Time Operating Systems What is a real-time operating system? Who needs real-time systems? QNX What is QNX? Microkernel IPC Process scheduling Process Manager Overview Process Life Cycle

althea
Télécharger la présentation

Real-Time Operating Systems - QNX

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  1. Real-Time Operating Systems - QNX Brett O’Neill CSE 8343 – Group A6

  2. Overview • Real-Time Operating Systems • What is a real-time operating system? • Who needs real-time systems? • QNX • What is QNX? • Microkernel • IPC • Process scheduling • Process Manager • Overview • Process Life Cycle • I/O Namespace • File Manager • Device Manager

  3. Real-Time Operating Systems What is a real-time operating system? From comp.realtime newsgroup faq: “A realtime system is one in which the correctness of the computations not only depends upon the logical correctness of the computation but also upon the time at which the result is produced. If the timing constraints are not met, system failure is said to have occurred.”

  4. Real-Time Operating Systems (cont.) • The value of the computation depends on the timeliness of the answer is provided. • Computations finished late have diminished value • Computations finished early have no extra value • Problems arise when resources are shared among several computations – real-time systems use schedules of activities so all activities will be completed in time

  5. Real-Time Operating Systems (cont.) • Hard Real-Time – A system constraint in which late computations have NO value, and the effects of late computations can be catastrophic. In hard real-time systems, activities MUST be completed on time. • Soft Real-Time – Late computations have some value, albeit diminished. Soft real-time systems can tolerate some late computations, as long as the value has not diminished to zero. • Meta requirements such as a stochastic model of the acceptable frequency of late computations are often used

  6. Real-Time Operating Systems (cont.) • Real-Time Systems have different types of activities: • Those that can be scheduled • Those that cannot be scheduled • Non real-time activities

  7. Real-Time Operating Systems (cont.) Who needs real-time systems? • Mission-critical environments requiring hard real-time, where timely performance failures can result in harm to people or property • Quality/Timeliness of service guarantee environments, particularly when failure to meet guarantees can result in financial penalties • Consumer devices that demand reliability –ie. live video stream players in which failure to deliver content results in dropped frame rates

  8. QNX What is QNX? • A commercial real-time operating system developed by QNX Software Systems Ltd. of Canada (QSSL) • Runs on X86 machines and clones: AMD, Nat Semiconductor, Cyrix, SGS Semiconductor • Provides multitasking, priority-driven preemptive scheduling and fast context switching

  9. QNX - Microkernel • “Bare bones” QNX consists only of a small kernel in charge of managing cooperating processes

  10. QNX - Microkernel • The microkernel has 4 main functions: • Routing messages between processes • Low-level network communication • Process scheduling • First-level interrupt handling

  11. QNX - Microkernel Message-based Inter-process Communication • A message is a packet of bytes synchronously transferred from one process to another • QNX does not attach meaning to the context of the message – the data in the message only has meaning to the sender and the receiver • C language functions Send(), Receive(), and Reply() are used

  12. QNX - Microkernel • Message passing synchronizes the execution of several cooperating processes. If Process A issues a Send() request, it cannot resume execution until Process B replies. And once Process B has issued its Receive() request, it cannot continue execution until it receives another message. • Processes that are not allowed to continue execution are blocked.

  13. QNX - Microkernel Proxy-based Inter-process Communication • A proxy is a non-blocking message used for event notification in which the sending process does not need to interact with the recipient • Proxies are used when: • A process wants to notify another process of an event, but does not want to risk sending a blocking message • A process wants to send data to another process but does not need acknowledgment of delivery • An interrupt handler wants to tell a process that some data is available • Proxies can queue up to 65,535 messages for delivery. They can be triggered more than once, sending a message for each trigger

  14. QNX - Microkernel Signal-based Inter-process Communication • Signals are a method of asynchronous communication • QNX supports POSIX-compliant signals, UNIX signals, and QNX-specific signals Network Inter-process Communication • Applications can communicate over a network transparently. QNX treats all processes the same, whether they are local or remote • Virtual circuits are used – these are paths provided by the Network Manager to transmit messages, proxies and signals

  15. QNX - Microkernel • Virtual Circuits: • The sending process is responsible for setting up a VC between itself and the receiving process. • Upon creation, the VC is given the ability to handle messages up to a specified size limit. If a message larger than the size limit is sent, the VC adjusts on the fly. • Two processes can communicate via multiple VC’s, combined into one logical VC. • Upon process termination, VC’s are automatically released. • Virtual proxies are also possible

  16. QNX - Microkernel Process Scheduling • The microkernel’s scheduler makes scheduling decisions at three points: • When a process becomes unblocked • When the time quantum for a running process expires • When a running process is preempted • Every QNX process is assigned a priority. The scheduler selects the process with the highest priority from the ready pool to run next. • Priorities range from 0 (lowest) to 31 (highest). Processes receive initial priorities from their parent processes. The default value is 10.

  17. QNX - Microkernel • QNX has 3 scheduling algorithms. These algorithms are of course only used when 2 or more processes that share the same priority are in ready status. If a higher-priority process becomes available, it immediately preempts all lower-priority processes: • FIFO Scheduling – A process continues to execute until it a) voluntarily relinquishes control or b) is preempted by a higher-priority process

  18. QNX - Microkernel • Round-Robin Scheduling – A process continues to execute until it a) voluntarily relinquishes control, b) is preempted by a higher-priority process, or c) consumes its time slice. A QNX time slice is 50 milliseconds

  19. QNX - Microkernel • Adaptive Scheduling – If a process consumes its time slice entirely, its priority is reduced by 1. This is called priority decay. Processes only decay once; if a process consumes more than one time slice, total reduction is only 1. If a process blocks, it immediately regains its original priority.

  20. QNX – Process Manager Overview • The process manager works with the microkernel to provide operating system services. It shares the same address space as the process manager, but runs as a unique process, scheduled by the microkernel. It uses the same types of IPC’s as all other QNX processes. • The process manager is responsible for creating new processes using C functions: • Fork() • Exec() • Spawn()

  21. QNX – Process Manager Process Life Cycle • Each process goes through 4 stages in its lifetime: • Creation – A unique process ID is created, and basic information is defined for the process’ environment. • Loading – Loader code in the process manager creates a loader thread that runs under the process ID of the new process. • Execution – The process is in direct competition with other processes for execution time. • Termination – A signal causes process termination, or the process invokes an Exit() function.

  22. QNX – Process Manager Process Life Cycle • Processes are always in one of the following states: • READY – capable of being executed • BLOCKED – the process is in one of these states: • SEND • RECEIVE • REPLY • SIGNAL • SEMAPHORE • HELD – the process has received a hold signal • WAIT – a child process has requested that the parent process wait • DEAD – the process has terminated but its parent is still running

  23. QNX – I/O Namespace • I/O resources are not built into the microkernel as in most operating systems. They are started dynamically while the system is running. Pathname space is not built into the file system. • Pathname space is divided into regions of authority. Any processes that required I/O must register a prefix with the process manager defining the portion of namespace it wants to administer. These prefixes are part of a prefix tree maintained on the computer.

  24. QNX – I/O Namespace • When a process opens a file, the file’s pathname is compared to the prefix tree to direct the Open() function to the correct I/O resource manager. • When an I/O resource is opened, the Open() function returns an integer called the file descriptor. All further I/O requests are directed by the file descriptor to the correct file manager. • The file descriptor namespace is completely local to each process.

  25. QNX – File Manager • The File Manager provides a standardized means of storing and accessing data on disks. • In QNX, a file is an object that can be read from, written to, or both. There are 6 types of files: • Regular – randomly accessible sequences of bytes with no predefined structure • Directories – contain the information needed to locate regular files • Symbolic links – contain a pathname to a file or directory that is to be accessed in place of the symbolic link file • Pipes and FIFO’s – I/O channels between cooperating processes • Block special – refer to devices; accessed in a manner that hides the hardware characteristics of the device from applications

  26. QNX – File Manager • The file manager maintains four times for each file: a) date of last access, b) date of last write, c) date of last modification, and d) date of creation • Access to files is controlled by bits called inodes. Inodes permit read, write and execute permissions by user, by group, and by other specifications.

  27. QNX – File Manager • The file manager has several means of maintaining high-performance disk accesses: • Elevator seeking – outstanding I/O requests are ordered so they can all be performed with one sweep of the disk head assembly, from lowest to highest disk address. • Buffer cache – a buffer between the file manager and the disk driver, the buffer cache tries to store all file system blocks to minimize the number of times the file manager needs to access the disk. • Multi-threading – the file manager is multi-threaded, therefore it can manage several I/O requests simultaneously. Several devices can be accessed in parallel, and I/O requests can be processed from the buffer cache while other I/O requests are accessing physical disks.

  28. QNX – File Manager • Client-driven priority – when the file manager receives a message, its priority is set to that of the process that sent the message. • Temporary files – data blocks are kept in cache to avoid writing blocks to a physical disk unless absolutely necessary. • Ramdisks – up to 8M of memory can be used as a simulated disk. Data moves directly from the ramdisk into application buffers.

  29. QNX – Device Manager • QNX’s device manager is an interface between processes and terminal devices. • Programs access terminal devices using the C functions Read(), Write(), Open() and Close(). • The device manager regulates the flow of data between applications and devices.

  30. Questions?

More Related