Process Communiction
The REAL/IX system supports a number of mechanisms that
allow a user-level or kernel-level process to communicate with a user-level
process. These include traditional system utilities and facilities
that are specific to the REAL/IX Operating System to support the functionality
required in realtime applications:
- signal mechanism
- common event notification that enhances the signaling facility
- shared memory, messages, and user-level semaphores
- binary semaphores, a very fast interprocess communication facility
In addition, the REAL/IX Operating System supports pipes
and named pipes. While these are useful for occasional transfers of
small amounts of information between processes because they are so
easy to code, they are generally too slow to be appropriate for realtime
applications, and are not discussed here.
Signal Mechanism
The signal mechanism is the traditional method of notifying
a process that something has happened in one program that affects
another program. Signals are part of the UNIX System V environment;
they are always asynchronous (meaning that the receiving process never
knows when it may receive a signal). The user-level program includes
code to determine the action to take when a signal is received (terminate
the process, ignore the signal, or catch the signal and execute a
subroutine). The receiving process does not know which process sent
the signal, and will react only to the first signal received; subsequent
signals are silently ignored.
How Signals Work
The REAL/IX signal mechanism functions just like the
traditional signal mechanism. While some internal modifications have
been made to provide better performance in the realtime environment,
signal-handling code from other UNIX systems will usually run without
modification on the REAL/IX system.
Signals are sent and received as follows:
- When the process is initialized, an array of signal-handling
fields is set up in the u area associated with the
process. Each field corresponds to a signal defined in the system,
and contains the address of the user function that corresponds
to the signal number (in other words, directions on the action
to take when a signal of that type is received). The fields for
any signals for which signal-handling functions are not provided
are set to 0, causing the process to exit when that type of signal
is received.
- The receiving process uses the sigset(2) system call
to define the function executed when a signal of the specified
type is received.
- The sending process sends a signal to another process (or group
of processes), identified by the process identification number
(PID).
- The appropriate signal-handling field in the u area of
the receiving process is marked when a signal is received; if
the process is not currently executing a critical region of code,
the designated action is taken immediately and the signal is cleared
from the proc structure. If the process is executing a critical
region of code, the signal is not handled and cleared until the
process exits from the critical region.
- As long as a process has an outstanding signal associated with
it, subsequent signals of the same type sent to the process are
silently discarded.
Process Groups
The concept of process groups is important when sending
signals. The default behavior is to define the process group as the
parent process plus all the child processes spawned by that parent.
At times, it is necessary to define some other process group. For
instance, if one starts a process from the shell, that process and
all its child processes belong to the process group of the shell.
The
setpgrp(1) command and
setpgrp(2)
system call are used to define a new process group, so that the signal
affects only the processes it should.
Signal sending is demonstrated in the following scenarios:
A user-level program sends a signal (defined on the
sigset(2) manual page) to another user-level program or group
of programs with the kill(2) system call or the kill(1)
command.
Signals may arrive at any time during process execution.
Signal-handling functionality is coded into the receiving process
using
On UNIX System V, Release 2 and earlier, signal handling
is coded with the signal(2) system call. UNIX System V, Release
3 added the sigset system call, which is a more reliable mechanism
for handling signals. Although the REAL/IX Operating System supports
both these system calls, we recommend using sigset.
The REAL/IX kernel supplements the traditional signal
mechanism with a high-performance event notification facility that
provides several features not found in signals. It handles notifications
synchronously as well as asynchronously, and queues multiple signals
sent to one process. This feature is important for realtime applications,
which typically need to respond to several events. It is a notification
method for asynchronous I/O completions, connected interrupts, timer
expirations, and resident memory violations, and you may also use
it for any application-specific needs.
Events are posted to a user-level process by itself
or another user-level process (using the evpost(2) system call)
or the kernel. A 32-bit data item is associated with each event posted;
it is received along with the event identifier. Typically, the data
item is a pointer to some common memory location. When an event is
posted, it is queued onto a list of events associated with the receiving
process. Each event queue is associated with a unique, per-process
event identifier. Like signals, these event queues are private to
the receiving process; an event posted to a queue is delivered only
to the process that created the event queue. Because they are queued,
events posted to the same event queue are not lost.
The receiving process determines whether the event
is delivered synchronously or asynchronously when it creates the event
identifier (eid). For synchronous delivery, the process uses
the evrcv(2) system call to receive the first posted
event on a single event queue or the evrcvl(2) system call
to receive the first event in a specific list of event queues, as
illustrated in Figure 4-1.
Figure 1 - Handling Events Synchronously
If no events are outstanding when the system call
is made, the process can specify whether to wait until an event is
posted or to return immediately with an indication that no event was
available.
For asynchronous delivery, process notification is
similar to the traditional signal mechanism, except that subsequent
events are delivered. When the receiving process creates the eid
for the specific signal number (as defined on sigset(2)), it
specifies the function for execution when that signal is received.
Asynchronous delivery implies that the receiving process has no control
over when the signal is received (except to block all signals); as
soon as the signal (asynchronous event) is received, the receiving
process handles it, as illustrated in Figure 4-2.
Figure 2 - Handling Events Asynchronously
The receiving process can create any number of separate
event queues, each of which can have its own method of delivery and
limit on the number of outstanding queued events.
One process can receive signals as well as synchronous
and asynchronous events. In general, all programs should include signal-handling
functionality, since the kernel or another user-level process may
send it a signal. A limited number of processes (defined by the tunable
parameter EVTMAXPRC) can receive and handle events. Critical realtime
programs requiring this functionality should use the event mechanism.
Any process executing on the system can post an event,
as long as the process has appropriate privileges:
The fastest interprocess communication is through
shared memory, where cooperating processes map the same area of memory
into their address space. When one process writes to a location in
the shared area, the data is available immediately by any other process
that has this location mapped in its address space. The time required
to access this location is no more than a normal memory reference.
All system overhead (other than address translation) associated with
this type of memory passing facility is eliminated.
You must use shared memory with another interprocess
communication mechanism (messages, semaphores, or binary semaphores)
to coordinate access to the shared memory region. Otherwise, it is
possible that one process may try to update the information while
another process attempts to read it, usually resulting in data corruption.
The REAL/IX system includes a binary semaphore mechanism
which is faster than the traditional interprocess communication (IPC)
user-level semaphore mechanism since it avoids unnecessary system
call overhead. This fast binary semaphore facility provides the synchronization
mechanism required by many applications to make shared memory a viable,
fast interprocess communication facility.
Binary semaphores are a REAL/IX Operating System
extension of UNIX System V semaphores. They differ from UNIX System
V semaphores in the following ways:
Binary semaphores are faster than UNIX System V semaphores,
and are appropriate for the vast majority of applications that do
not require the full power of the traditional System V semaphores.
For more detailed information about the binary semaphore refer to
the Programmer's Guide.
Messages are a common mechanism for interprocess
communication. The message facility uses a message queue, into which
messages are sent and from which messages are received. Figure 4-3
illustrates a simple message queue used for communications between
two processes.
Figure 3 - Sending and Receiving Messages
The UNIX System V implementation of messages dynamically
allocates messages as they are needed. The REAL/IX Operating System
implementation also allows you to preallocate messages when you create
the message queue.
Go to Chapter 5 TOC
is a subsidiary of 