Embedded Systems -> OS world seeks a portable interface

OS world seeks a portable interface

OS world seeks a portable interface
By Kevin M. Obenland, Director of Systems Architecture, Science Applications, International Corp., Arlington, Va., EE Times
April 6, 2001 (2:19 p.m. EST)
URL: http://www.eetimes.com/story/OEG20010406S0052

The original Portable Operating System Interface for Computing Environments (Posix) standard, first published in 1990, is based on Unix, a well-established technology dating back to the early 1970s. It defines a standard way for an application to interface to the operating system. The original Posix standard defines interfaces to such core functions as file operations, process management, signals and devices. Subsequent releases of Posix have also been defined to cover real-time extensions and multi-threading.

In a perfect world, one would always choose a standard. However, in the real world there are a number of questions one needs to ask before deciding to use a standard:

Does the standard provide the functionality needed by the intended application?

Is the performance or implementation of the standard suitable for the application?

Do commercially available implementations of the stan-

dard exist?

In the c ontext of Posix, the best way to assess its usefulness is to look at its implementation in relation to three factors-functionality, performance and availability-on some typical commercial operating systems (OSes), in this case Linux, LynxOS, QNX Neutrino and Solaris.

Predictable timing
To guarantee that the timing requirements of a real-time system are met, the behavior and timing of the underlying computing system must be predictable. For the timing of the system to be called predictable, the time required by all operations must be bounded. That implies that the worst-case timing of all operations is known. Typically, a system is called predictable only if its worst-case timing is very close to its average-case timing.

Of the more than 30 Posix standards, seven are especially relevant to the development of real-time and embedded systems. Posix 1003.1a defi nes the interface to basic operating system functions and was the first to be adopted in 1990, while real-time extensions are defined in the standards 1003.1b, 1003.1d, 1003.1j and 1003.21. However, the original real-time extensions, defined by 1003.1b, are the only standards commonly implemented. Support for multiple threads in a process is provided in a separate standard, Posix 1003.1c. Posix also includes support for high availability in the 1003.1h standard.

Posix 1003.1b, as well as 1003.1d and 1003.1j, defines extensions useful for development of real-time systems. Functions defined in the original real-time extension standard 1003.1b are supported across a wider number of operating systems than the other two specifications. For that reason, this article focuses on Posix 1003.1b. The following constitute the bulk of the features defined in Posix 1003.1b:

Timers. Periodic timers are defined, with delivery accomplished using Posix signals.
Priority scheduling. Fixed priority pr eemptive scheduling provides a minimum of 32 priority levels.
Real-time signals (additional signals with multiple levels of priority).
Named and memory-counting semaphores.
Memory queues-message passing using named queues.
Shared memory-named memory regions shared among multiple processes.
Memory locking-functions to prevent virtual memory swapping of physical memory pages.

For the purposes of evaluating the real-time performance of the various operating systems, a C-language program for creating and using a Posix timer can be used. Creating a timer consists of two steps: specifying a signal to be used to deliver the timer and creating/setting the timer itself.

In this example, we use the highest-priority real-time signal (sigrtmin) to asynchronously call the timer handler routine. Two values must be specified for the timer: the initial expiration time (it_value) and the frequency (tv_sec). The structure (itimerspec) allows nanosecond time specification; however, ac tual resolution is dependent on the system. The Posix call clock_getres() can be used to determine the actual resolution, typically 10 or 1 millisecond.

Varied compliance
As can be expected, there are varying levels of compliance with Posix 1003.1(a/b/c) among the several commercially available operating systems. General-purpose operating systems like Solaris and Irix are the most compliant. LynxOS conforms to Posix 1003.1a and with the 3.1 release will be very close to full compliance to the three standards. VxWorks only supports a subset of the Posix standards, because VxWorks is based on a single process model. VxWorks uses its own threading library, but a Posix thread implementation is provided through a third-party vendor. Linux provides good support for the base Posix APIs and threads,but is missing real-time features such as timers and message queues.

Solaris, a general-purpose Unix operating system available from Sun Microsystems and developed to run on Sparc and Pentium-class CPUs, has many of the features required for a real-time system.

Solaris implements both user-level and kernel-level threads. User-level threads are implemented as a library at the user application level; kernel-level threads are the unit of execution seen by the kernel.

Solaris uses the lightweight processes (LWP) mechanism to run kernel-level threads on processors. The mapping of user-level threads to LWPs can be done in a number of different ways. If multiple user-level threads are mapped to a single kernel-level thread, then at most one thread can be active at a time. To take advantage of multiple processors, user-level threads can be mapped one-to-one to LWPs.

LynxOS is a Unix-style operating system developed for real-time embedded systems. The Lynx kernel is pre-emptable, re-entrant and can be scaled down to a footprint as low as 97 kbytes. LynxOS 3.0.1 supports a single scheduling policy, fixed-priority pre-emptive with 256 priority levels. The clock tick frequency is fixed at 1 00 Hz, which limits the resolution of timers to 10 ms. The scheduler is also invoked in response to asynchronous events and a change in the system state.

The six benchmarks used in this study are divided into two categories: those that measure the determinism of the OS and those that measure the latency of important operations. The benchmarks test core operating system capabilities and they are independent of any actual application.

The first three benchmarks-timer jitter, response and bintime-are designed to measure the determinism of an operating system.

The time-jitter test creates a timer, sets it to expire at a given period, and when it expires, determines the actual expiration time. The jitter is then defined as the deviation between the actual and desired expiration times. Most current CPUs include a stamp counter that is updated on every CPU cycle.

The second deterministic benchmark (response) measures the actual execution time of a 10-ms fixed block of processing. The actual execution time over a number of separate runs is calculated to determine whether or not application response time is deterministic.

The last deterministic benchmark (bintime) determines the maximum kernel blocking time. This benchmark uses a high-priority real-time thread to repeatedly call a time-of-day clock and calculate the time required by each call.

The message-passing benchmark uses Posix message queues to measure the latency and throughput of data transfers between two threads in the same process or in different processes.