Partitioning Operating Systems

Understanding RTOS and embedded Linux systems, is it a process? Is it a partition?

lynxos-178-50px1Partitioning operating systems are the latest buzz—largely based on an ARINC 653-style separation scheme. Processes, by contrast, have been around for over 30 years in a classic UNIX®/POSIX® model and provide the most portability between UNIX and Linux® systems. Both provide memory protection, however, the intent behind them is very different.

Partitioning operating systems like the LynxOS-178 RTOS have evolved to fulfill security and avionics requirements where predictability is extremely important. In avionics systems, for instance, running interrupts other than the system clock needed for cycling the partitions is discouraged.



In a partitioning operating system, memory (and possibly CPU time as well) is divided among statically allocated partitions in a fixed manner. The idea is to take a processor and make it pretend it is several processors by completely isolating the subsystems.

Hard partitions are set up for each part of the system, and each has certain amount of memory (and potentially a time slice) allocated to it. Each partition is forever limited to its initial fixed memory allocation, which can neither be increased nor decreased after the initial system configuration.

Within each partition may be multiple threads or processes, or both, if the operating system supports them. How these threads are scheduled depends on the implementation of the OS. A partition will generally support a separate namespace to enable multi-programming by mapping the program into the partition.

If the operating system supports time partitioning, it too is fixed. For example, in an ARINC 653 partitioning system with just three partitions and a total major allocation of 100ms per cycle, a fixed cyclic scheduler could be set to run the first partition for 20 ms, then the second partition for 30 ms, and then the third for 50 ms.

LynxOS-178 is an ARINC 653 partitioning operating system that supports multiple POSIX processes and multiple address spaces; priority scheduling; priority inheritance; and priority ceilings within each partition. LynxOS-178 essentially moves the LynxOS scheduler and operating system up a level into each partition, with a full ARINC 653 partitioning operating system underneath.



In a process model or thread-based system, processes protect and separate memory from each other, but they are dynamic rather than fixed.

A process can be dynamically loaded into memory from a fully linked executable located on the hard drive or on a RAM disk in memory. Then, a main thread is created and assigned to the process, and it is scheduled.

Because a process is NOT limited in how much memory it can have, additional memory can be dynamically allocated to it as needed during program execution.

Instead of cyclic scheduling like an ARINC 653 system, a process-based system runs priority-based preemptive scheduling based upon the priority of the threads. The performance of process-based systems is improved if the operating system handles priority inheritance efficiently and if it incorporates preemptible kernel technology.

A thread-based scheduler has more work to do than one that just cycles partitions because it needs to respond to the individual priority values of the threads it manages. Since each thread runs inside the memory context of a particular process, a context switch between threads within the same process takes less time than a switch between threads in separate processes.

Processes provide inherent memory protection by isolating their resident threads and memory from other processes. Despite this security measure, a process could still potentially exhaust system memory by continually forking more child processes.

Additionally, a runaway thread could also exhaust a system by requesting (and receiving) all the CPU time if it happens to be the highest priority thread. A watchdog timer is often used to prevent such situations.


Even though threads in one process can’t overwrite threads in another, some spill-over between processes could possibly occur anyway because system memory is typically also accessible via a virtual address space (to allow the dynamic creation of additional threads, processes or OS structures). All memory areas aren’t necessarily flushed on a process switch.

Some POSIX calls require that data be shared between processes. A dynamic library for instance will require that the code space of the library be shared between two or more processes by mapping the library area into both processes.

An mmap() call also can map a global memory area into the visibility of multiple processes. Both dynamic libraries dlopen() and mmap() are required by POSIX profile 54.

On a process-model operating system that supports shells and utilities (also POSIX profile 54) a user can log into the target operating system and dynamically invoke a new process by typing the ps command. The shell will locate the ps utility off the ram disk in /bin, fork a new process, and execute the ps program.


The process-thread model is used by both Linux and Solaris™ systems, but the actual implentation differs according to “scope.” The POSIX standard defines both SCOPE_LOCAL and SCOPE_GLOBAL.

Solaris usually schedules all threads within a process first, and then processes are scheduled as a block based according to the priority of the process—SCOPE_LOCAL (typical UNIX implementation).

On the other hand, an operating system like the LynxOS RTOS will look across all of the threads in the system, regardless of which process they belong to, when deciding which thread to run next—SCOPE_GLOBAL.


LynxOS is a process-model operating system with global priority-based, preemptive scheduling at the thread level across the entire system (all processes). it supports both priority inheritance and priority ceiling protocol.


Partitioning operating systems like the LynxOS-178 RTOS are powerful when it is necessary to completely isolate portions of the system from each other. For example, the activities of the CPU in a plane’s cockpit control system must be predictable and known at all times, and the fixed, cyclic nature of a partitioning operating system’s scheduler makes this possible. Without fixed time-slice partitioning, a rate monotonic analysis would need to be performed to know exactly where a system is executing.

Conversely, a global, thread-scheduler, process-based operating system such as the LynxOS RTOS best serves the requirements of a system with an I/O device that could burst, such as a radar system. Such a system must be capable of responding to bursting hardware with all the system resources available. This can only be achieved by denying processing time to other parts of the system, which would not be permitted under a partitioning operating system and its unmodifiable processing-time allotments.