Corporate What's New? Support Contact Us Home



 

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

 


E-Mail Webmaster  | Legal | Copyright © 2001 MODCOMP, Inc. | Rendered Sept. 28, 2001

MODCOMP is a subsidiary of CSP Inc