Introduction
Realtime applications are concerned with the timing
of when events occur and are dependent on the underlying system to
facilitate the necessary services to support this basic requirement.
The underlying system can be a dedicated hardware circuit driving
something as simple as a traffic light or it can be an embedded system
controlling the anti-lock breaks on your car. It can be a complex
system which requires the sensing and control of a multitude of external
devices such as the control and guidance system of the Space Shuttle
or the manipulation of the fuel rods in a nuclear reactor. No matter
what the application realtime tasks require reliable time critical
services. As technology evolves and computing machines become faster
and cheaper there is a tendency to adopt the notion that realtime
requirements can be solved by a machine which is fast and dedicated
but not necessarily running a realtime operating system. This is a
risky approach as a non-realtime system can not predictably preempt
itself to execute code in response to an external event nor will it
provide the system services to process such events.
This white paper introduces the MODCOMP REAL/IX Operating
System, which is a realtime operating system based on the UNIX System
Laboratories, Inc. UNIX System V operating system. In its standard
form UNIX is a timesharing operating system with very powerful features
including a large third party application install base and a wide
range of peripheral and controller support. It also provides a programming
environment which facilitates the rapid development of software which
has created a surplus of software developers over the years. MODCOMP
has taken this very popular open system and has extended it to conform
to meet industrial standards for realtime computing. REAL/IX has emerged
as one of the most powerful realtime operating systems in the market
today.
Background
Readers who are not familiar with UNIX operating systems
should read the entire white paper as a background; readers who have
experience with other UNIX operating systems may want to skip over
some sections. The Preface lists the other books published by MODCOMP
to support the REAL/IX Operating System; Chapter
10 is a general bibliography of some commercially-available books
and articles that discuss various facets of UNIX operating systems.
Evolution of UNIX Operating Systems
The history and evolution of UNIX operating system is
an interesting story that is explained in detail in several of the
books listed in the bibliography; we will summarize that history here.
In 1969, Ken Thompson and Dennis Ritchie of Bell Laboratories
began work to develop what Dennis Ritchie later called a "convenient
interactive computing service." They sketched out a file system
architecture, developed an interpretive programming language called
B, and gradually evolved a primitive operating system that ran on
Digital Equipment Corporation's (DEC) PDPC-7 computer.
Over the next five years, the operating system was migrated
to the DEC PDP-11 system. Ritchie developed the C programming language,
which allowed the generation of machine code, declaration of data
types, and definition of data structures. In 1973, the operating system
itself was rewritten in C, and in 1974 Thompson and Ritchie published
a paper in the Communications of the ACM , describing what
is now known as Version 3 of the UNIX operating system. At this time
there were about 25 UNIX system installations at Bell Laboratories.
Because of a 1956 consent decree signed with the federal
government, AT&T could not market any computer products. They
could, however, provide copies of the UNIX system to universities
for educational purposes, which they did. The UNIX system was also
used for business applications at the local telephone operating systems,
and a version was developed that served as a base for the network
switching systems used to manage telephone traffic. By 1977, there
were about 500 UNIX system sites, of which 125 were at universities.
In 1977, AT&T provided a license for the UNIX system to Interactive
Systems Corporation, the first commercial contract.
These early versions of the UNIX system were known by
the edition of the manuals that described them: Version 5 in 1974,
Version 6 in 1976, Version 7 in 1979. Version 7 is the common ancestor
of virtually all UNIX operating systems in existence today.
One of the universities that was working with the UNIX
operating system was the University of California at Berkeley. In
1980, the Department of Defense chartered the Berkeley group to redesign
the UNIX system into an appropriate vehicle for research into distributed
computing. The result is commonly known as 4BSD, for Fourth Berkeley
Software Distribution. The early Berkeley versions introduced such
enhancements as a larger process address space, demand-paged virtual
memory, facilities to support local networking, a full screen editor,
and a generic interface for intelligent terminals.
Between 1977 and 1983, AT&T Bell Laboratories combined
several AT&T variants into a single system, known commercially
as UNIX System III. AT&T continued to add enhancements, and in
January 1983 announced support for UNIX System V.
On January 1, 1984, AT&T was divested as a result
of an earlier court settlement: the local telephone operating companies
ceased to be a part of AT&T and became, instead, seven individual
corporations. By this point, there were about 100,000 UNIX system
installations in the world, running on a variety of hardware platforms.
As a part of the divestiture agreement, the 1956 consent agreement
was canceled, opening the way for AT&T to market the UNIX operating
system and their own hardware platforms.
Since then, the popularity of UNIX operating systems
has grown by leaps and bounds. Several popular journals are dedicated
to UNIX operating systems, and virtually every major computer vendor
offers a version of this software.
Standardization
Over the years, a number of variations of UNIX operating
systems have evolved. While all these variants have a common ancestor,
the differences between versions were, ironically, starting to threaten
the portability that is one of the major advantages of the UNIX system.
A number of attempts were made to standardize the user-level interfaces
of the operating system. The major one is the ANSI/IEEE committee
1003 (POSIX).
The POSIX group is a standardization effort that includes
a broader base of corporations. With the growing interest in realtime
operating systems, a subgroup was spun off to standardize a set of
user-level extensions for realtime operating systems based on the
POSIX standard. MODCOMP is an active participant in the POSIX 1003
standardization efforts.
The REAL/IX Operating System supports numerous porting
bases. Standards of interest for these porting bases include the IEEE
POSIX Standards 1003.1 and 1003.1b and FIPS 151-2. Contact your MODCOMP
sales representative for details about the conformance of the REAL/IX
Operating System to these and other applicable industry standards.
You may also wish to refer to the appropriate publications listed
in Chapter 10 that describe these
standards.
Realtime Computing
MODCOMP defines realtime computing as the ability to
respond to asynchronous external events in a predictable (preferably
fast) time frame. This requires balanced performance on three dimensions:
instruction execution, interrupt latency, and I/O throughput. In addition
to sufficient computational power (which is also required for time-sharing),
realtime systems must provide efficient interrupt handling and high
I/O throughput to meet the needs of the realtime application.
A realtime operating system must respond to some internal
or external event in a deterministic time frame, regardless of the
impact on other executing processes. This is distinguished from a
time-sharing operating system, which must share system resources (such
as the CPU, primary memory, and peripheral devices) equitably among
a number of executing processes. In a properly-configured time-sharing
environment, no process should wait indefinitely for a system resource.
In a realtime environment, critical processes must receive the system
resources they need when they need them, without concern for the effect
this may have on other executing processes.
With the escalating costs of software development and
the need for porting realtime applications to state-of-the art hardware
without massive conversion efforts, there is a need for realtime applications
to be portable so that they can be moved to newer hardware platforms
easily. UNIX operating systems are designed for portability, but have
traditionally lacked a number of features required to support realtime
applications.
The major weaknesses of UNIX System V for realtime applications
are the lack of a preemptive kernel and the limited ability to preallocate
resources for a process. A preemptive kernel is one in which a high-priority
process can preempt the CPU from an executing process at a lower priority.
Without this feature, a low-priority process might block a high-priority
process. UNIX System V has a non-preemptive kernel: an executing process
relinquishes the CPU to wait for some hardware or software event or
when it receives an interrupt from the hardware, but not because it
is blocking a higher-priority process.
The REAL/IX Operating System is a fully preemptive,
low-latency, realtime UNIX kernel that provides a user environment
similar to that of UNIX System V but with extensions that provide
the capabilities required by realtime applications. These are summarized
here by the major subsystems of UNIX operating systems: process subsystem,
interprocess communications, file subsystem, and I/O subsystem.
Process Subsystem
The REAL/IX process subsystem includes the following
enhancements required by realtime applications:
- fully-preemptive kernel with synchronization mechanisms to ensure
data structure integrity.
- fixed-priority based process scheduler for critical realtime
processes.
- realtime timer mechanisms.
- enhanced memory management facilities that support preallocation
of memory resources.
Interprocess Communications
UNIX System V supports several interprocess communication
mechanisms: signals, shared memory, semaphores, and messages. These
facilities are fully supported on the REAL/IX Operating System, with
the following extensions:
- common event notification mechanism that is more reliable than
the signal mechanism (because more than one signal of a given
type can be queued at once) and allows receiving signals synchronously
as well as asynchronously.
- binary semaphore mechanism, which is a faster version of the
UNIX System V semaphore mechanism.
File Subsystem
The REAL/IX file subsystem provides the following enhancements
to the UNIX System V file subsystem:
- alternative file system architecture that supports preallocation
of space and contiguous files.
- ability to bypass the buffer cache for file I/O.
- synchronous updates of physical storage devices.
- larger logical block sizes for faster throughput to files.
- improved locality of reference.
I/O Subsystem
The REAL/IX I/O subsystem enhances the UNIX System V
I/O subsystem with the following capabilities required for realtime
computing:
- support for emulating asynchronous I/O operations.
- disk I/O queuing prioritized according to the process priority.
- direct I/O between a user-level program and a device.
- connected interrupts for notifying a user-level process of a
hardware interrupt.
Other Enhancements
A number of other modifications are made enabling the
REAL/IX Operating System to provide the control and performance required
for realtime computing. Most of these are internal modifications and
completely transparent to users, but some are visible:
- A number of daemons are added to the system providing necessary
kernel functionality (such as writing error messages to the console)
without degrading system interrupt latency. Many of these daemons
and other system processes have tunable parameters that determine
their execution priority.
- The SCSI interface simplifies the administrative tasks involved
in adding disk and tape devices to the system as well as providing
the flexibility of the SCSI interface.
- System calls are installed into the kernel by entering them
in a table and relinking the kernel. On other UNIX operating systems,
system calls (which execute with less overhead than library routines)
require recompilation of the kernel and only those customers who
have source code may install this type of call.
- A new device /dev/smem (safe memory) used solely for
reading or writing memory providing improvements to the address
validation process.
Summary of REAL/IX Extensions
Table 1-1 lists the commands, system calls, library
routines, and data structures that provide the functionality described
above. These are listed with the appropriate manual page reference
in parentheses; refer to Manual Page Format in Chapter 2 for an explanation
of the organization of the manual pages.
In addition to these new components, a number of traditional
entities have expanded functionality to support the realtime features.
These are listed after Table 1-1.
| Feature |
Manual Page |
Description |
Realtime
Priorities
and
Privileges |
setrtusers(1M)
setrtusers(2)
|
assign realtime privileges to a user |
| rtusers(1) |
get list of users with realtime privileges |
| setrt(2) |
set realtime privileges for a process |
| clrrt(2) |
remove realtime privileges for a process |
| getpri(2) |
get scheduling priority |
| setpri(2) |
set scheduling priority |
| suspend(2) |
suspend calling process |
|
resume(1R)
resume(2)
|
resume a suspended process |
| rtusers(1) |
view the realtime privileged users list |
| swtch(2) |
switch into a process |
| relinquish(2) |
voluntarily give up CPU |
| setslice(2) |
set CPU time slice size |
Kernel
Synchronization |
psema(D3X)
cpsema(D3X)
decsema(D3X)
|
decrement value of kernel semaphore |
|
vsema(D3X)
cvsema(D3X)
incsema(D3X)
|
increment value of kernel semaphore |
| valusema(D3X) |
check value of kernel semaphore |
| initsema(D3X) |
initialize semaphore |
| spsema(D3X) |
get spin lock |
| svsema(D3X) |
release spin lock |
|
valuelock(D3X)
cspsema(D3X)
|
check value of spin lock |
| initlock(D3X) |
initialize spin lock |
Realtime
Timer
Mechanisms |
adjtime(2) |
make small changes in the system clock |
|
absinterva(2)
incinterval(2)
|
set value of process interval timer |
| getinterval(2) |
get current value of process interval timer |
| gettimer(2) |
return current system time |
| gettimerid(2) |
get a process interval timer |
| nanosleep(2) |
suspend execution of a process |
| reltimerid(2) |
release a process interval timer |
|
resabs(2)
resinc(2)
|
return resolution and maximum value of process
interval timer |
| nanosleep_getres(2) |
return resolution details for the nanosleep function |
| restimer(2) |
get resolution and maximum value of system-wide
realtime timer |
Memory
Allocation |
settimer(2) |
set current value for a system-wide realtime timer |
| itimerstruc(4) |
format of process interval timer value |
Common
Event
Mechanism |
timestruc(4) |
format of system-wide realtime timers |
| resident(2) |
lock memory segments in memory |
| stkexp(2) |
preallocate memory for stack |
| evctl(2) |
event control operations |
| evget(2) |
get an event identifier |
Binary
Semaphore
Mechanism |
evpost(2)
send_event(D3X)
|
post an event to a process |
|
evrcv(2)
evrcvl(2)
evrcvm(2)
|
receive a queued event synchronously |
| evrel(2) |
release an event identifier0 |
| bsget(2) |
get a binary semaphore |
| bsfree(2) |
free a binary semaphore |
Fast File
Systems |
bslk(3C) |
lock a binary semaphore |
| bslkc(3C) |
conditionally lock a binary semaphore |
| bsunlk(3C) |
unlock a binary semaphore |
Asynchronous
I/O |
estat(2)
efstat(2)
|
get status of extended file |
| trunc(2) |
truncate file space |
|
prealloc(1R)
prealloc(2)
|
preallocate contiguous file space |
|
arinit(2)
awinit(2)
|
initialize structures for asynchronous I/O |
|
aread(2)
awrite(2)
|
initiate asynchronous I/O transfer |
|
acancel(2)
comp_cancel_aio(D3X)
|
cancel asynchronous I/O operation |
Connected
Interrupts |
arwfree(2) |
free structures for asynchronous I/O |
| aio(D2X) |
driver entry point for asynchronous I/O |
| comp_aio(D3X) |
mark completion of asynchronous I/O transfer |
| cintrio(7) |
connected interrupt interface |
| cintrctl(D3X) |
connected interrupt I/O control operations |
Other
Features |
cintrget(D3X) |
connect driver to a connected interrupt identifier |
| cintrnotify(D3X) |
notify user-level process of an interrupt |
| cintrelse(D3X) |
release a connected interrupt identifier |
| aconf(1M) |
automatic SCSI disk and tape setup |
| db(1M) |
kernel debugger |
| kdb(1M) |
kernel debugger |
| select(1M) |
synchronous I/O multiplexing |
| sysent(4) |
structure for adding system calls to kernel |
Table 1 - Summary of REAL/IX Features
The following standard components have enhanced functionality
to support these features. These are summarized by manual section
below:
- Section 1 lpioctl, ls, ps
- Section 1M crash, dcopy, ddefs, fsck, mkfs
- Section 2 brk, exec, exit, fcntl, fork, shmctl, shmget,
shmop, stat, sysm*k
- Section 4 fs, inode, master, profile
- Section 5 fcntl, stat
- Section 7 lp
The REAL/IX Operating System also includes a number of commands and
system calls documented as NOSUPPORT and packaged on a separate tape.
These are public domain tools that we either developed or gathered
from other sites. MODCOMP does not guarantee that they work on this
release, although they are used with some success on our development
machines. NOSUPPORT tools come with source code and online manual
pages if they are available.
Go to Chapter 2 TOC