This section describes the interprocess communication (IPC) interfaces of Oracle Solaris as the interfaces relate to real-time processing. Signals, pipes, FIFOs, message queues, shared memory, file mapping, and semaphores are described here. For more information about the libraries, interfaces, and routines that are useful for interprocess communication, see Interprocess Communication.
The sender can use sigqueue() to send a signal together with a small amount of information to a target process.
To queue subsequent occurrences of a pending signal, the target process must have the SA_SIGINFO bit set for the specified signal. For more information,see the sigaction(2) man page.
The target process normally receive signals asynchronously. To receive signals synchronously, block the signal and call either sigwaitinfo() or sigtimedwait(). For more information, see the sigprocmask(2) man page. This procedure causes the signal to be received synchronously. The value sent by the caller of sigqueue() is stored in the si_value member of the siginfo_t argument. Leaving the signal unblocked causes the signal to be delivered to the signal handler specified by sigaction(), with the value appearing in the si_value of the siginfo_t argument to the handler.
A specified number of signals with associated values can be sent by a process and remain undelivered. Storage for {SIGQUEUE_MAX} signals is allocated at the first call to sigqueue(). Thereafter, a call to the command either successfully enqueues at the target process or fails within a bounded amount of time.
Pipes, named pipes, and message queues behave similarly to character I/O devices. These interfaces have different methods of connecting. For more information about pipes, named pipes, and message queues, see Pipes Between Processes, Named Pipes, System V Messages, and POSIX Messages.
Semaphores are also provided in both System V and POSIX styles. For more information, see System V Semaphores and POSIX Semaphores.
Note that using semaphores can cause priority inversions unless priority inversions are explicitly avoided by the techniques mentioned earlier in this chapter.
The fastest way for processes to communicate is directly, through a shared segment of memory. When more than two processes attempt to read and write shared memory simultaneously, the memory contents can become inaccurate. This potential inaccuracy is the major difficulty with using shared memory.
To avoid such inaccuracy, you can use the APIs of the libmemcontext library. These APIs enable you to control access to a shared memory. Using this library prevents a thread from accessing memory that is not relevant to its current operation. If memory context is enabled, before accessing the memory segment, a process locks the memory for its use on entry and releases the lock on exit. This process ensures that multiple processes will not be able to modify the memory segment at the same time. This feature is useful when you are working with in-memory databases.