From - Sun Nov 24 09:36:31 1996 Path: lab!ipmce!demos!news.stealth.net!news.ibm.net.il!arclight.uoregon.edu!hammer.uoregon.edu!hunter.premier.net!news.mathworks.com!howland.erols.net!agate!news.ucsc.edu!osr From: valentin@netcom.com (Valentin Pepelea) Newsgroups: comp.os.research Subject: Re: Real Time OS vs uh, Non Real Time Date: 22 Nov 1996 18:56:24 GMT Organization: Netcom Communications, Santa Clara, CA Lines: 114 Approved: comp-os-research@ftp.cse.ucsc.edu Message-ID: <574t0o$4qd@darkstar.ucsc.edu> References: <55la0j$dij@darkstar.ucsc.edu> NNTP-Posting-Host: ftp.cse.ucsc.edu Originator: osr@cse.ucsc.edu X-Mozilla-Status: 0011 Content-Length: 5681 In article <55la0j$dij@darkstar.ucsc.edu> adamsch1@cps.msu.edu (Christopher Shane Adams) writes: > > Just curious, any OS guru's out there wish to give me a list of differences >between a real time OS and a non Real time OS? The basic difference between the two is that a real-time OS is deterministic. That means that the behavior of the operating system is predictable, and can be calculated given a certain load. This has implications for allelements of the operating system. Let's compare the elements of typical real-time operating system (RTOS) to an older version of Unix, SVR3, since that version had no real-time features built in. Scheduler --------- In the RTOS, the relative priorities of tasks are strictly enforced. When a higher priority task is ready to run, it is guaranteed to be run within a deterministic amount of time. Under SVR3, priorities of processes fluctuate depending on their activities. Memory Allocation ----------------- Memory is allocated from several pools of fixed-sized memory blocks. The size of blocks varies along pools. This allows applications to allocate and release memory blocks in random order, and be guaranteed that memory remains available in consistent amounts as time progreses. Under SVR3, memory is allocated from heaps. Continuous allocation/release can lead to fragmentation and failure to allocate sufficient memory as time progresses. Interrupt Latency ----------------- Usage of interrupt disable instructions for mutual exclusion is minimized in the RTOS, and maximum disable times are usually calculated and published by the vendor. Interrupt entry and exit code is also minimized and deterministic. Preemptable Calls ----------------- Under SVR3, process scheduling is suspended during system calls until call completes. This can cause a higher priority task to wait too long to be started. RTOSes solve this problem in one of two ways: older RTOSes such as VRTX and pSOS are written in assembly, and their system calls complete very quickly, allowing for the calculation of small scheduling latency times. Newer RTOSes such as VRTXsa are written in C, and their system calls are pre- emptable, as scheduling and interrupts are disabled withing the system call only for the short critical sections necessary. Synchronisation --------------- RTOSes typically offer synchronisation capabilities through event flags. Tasks may wait on several events simultanously. If a higher priority task's event is set when that tasks is already waiting for it, the higher priority task is guaranteed to be run within a deterministic amount of time. SVR3's signals are a poor substitute, as signal occurance is not recognized until the kernel's regular rescheduling checks. Simultanous pending on kernel objects of different types is not possible. Message passing --------------- Real-time applications are typically a collection of communicating tasks. Efficient message passing calls are therefore provided. Messages arrive deterministically in prioritized order. Under SVR3, inter-process message passing is an afterthought, performed either through bulky Berkley sockets, or though the file system, such as pipes. -- In addition to the features stated above, RTOSes have other features which are not typical of non-realtime OSes. An RTOS is typically small, since it is often used in an embedded application, such as a cellular phone, VCR or car. It is also fast, in addition to being deterministic. Mutual exclusions mechanisms, such as semaphores and monitors are also present, given that data objects are often shared in common memory. RTOS vendors strive to make their kernels scalable, so that they may leverage development efforts for a large set of applications. Modern RTOSes may therefore start at around 4K in size, and grow to 500K or more as file systems, communication stacks and GUIs are added. Some kernels even allow you to selectively exclude communication, memory allocation and mutual exclusion mechanisms to make the kernel smaller. Development systems are typically more powerful than what is available for desktop operating systems. RTOS debuggers let you set per task breakpoints, allow you to create separate windows for every task and allow you to get instantaneous statuses of tasks, message queues, event flags, memory and other kernel objects. Some debuggers also allow you to set breakpoints in interrupt service routines, and some allow you to stop the entire system, so that you may monitor the status of the apprication and kernel in a frozen state. I have used SVR3 as an example above, because modern desktop non-realtime operating systems often include some real-time features. Most popular today is the addition of a real-time scheduler, message passing and mutual exclusion mechanisms. They typically still fail in interrupt latency and system call features, though. These additions have turned some variants of Unix and Windown NT into acceptable soft-realtime operating systems. Many interactive applications benefit from these features. Given that the effort to re-architect these operating systems into hard-realtime systems is not difficult, we could expect see RTOSes on our desktops within the next decade. > From: adamsch1@cps.msu.edu (Christopher Shane Adams) > Organization: Michigan State University I hope this answer will help you get a good grade on your assignement. :-) Valentin -- "An operating system without virtual memory Valentin Pepelea is an operating system without virtue." Embedded Sytems Consultant (415) 346-7105 - Ancient Inca Proverb valentin@netcom.com