Chapter 24. Interprocess Communication


Interprocess communication, also known as IPC, covers the facilities offered by the operating system to allow processes to share information. In general, a process can access only its own address space, so the only way data can be shared is if that data can be found in a common area. The simplest answer is to put the data into a file, but this is slow, imposes lots of overhead ( especially if the data won't be needed again), and presents some problems with synchronization and locking. The real answer is to make the kernel provide some way to ship data back and forth without involving physical I/O.

The first attempt used pipes . These were implemented as short (4K) kernel buffers that would allow one process to write data in and another process to pull data out. Normal read and write operations were used, but the data never left the kernel. The main problems with this method were a limited transfer rate (small buffers) and the fact that the pipe had to be set up by a common parent process. You couldn't set up a pipe to talk to an already running daemon, for example.

Several extensions appeared. AT&T created named pipes (fifos), with an entry in the file system, which allowed unrelated processes to communicate. The BSD kernel used the network communications facilities (sockets) to set up data paths between processes on the same machine with UNIX domain sockets, which also used an entry in the file system.

More choices became available when message queues, semaphores, and shared memory facilities were added to the kernel. These were applicable to processes on the same machine and could not be used for network applications. Sockets continue to be a primary method for data transfer between processes on different machines, although in Solaris 2 these became library functions; the underlying implementation now uses the Transport Level Interface (TLI) and Streams.

We'll concentrate here on the SVR4 IPC facilities that have been in SunOS kernels since before release 4.0: messages , semaphores , and shared memory .

To use each of these different facilities, a user process must create a "pseudo-file," that is, something with a name or key to identify it, an owner, access permissions, sizes, and so forth, although the pseudo-file never makes it out to the file system. This object is created by a system call that defines some kernel tables and is "opened" by another system call when a process wants to use it. Messages allow short chunks of data to be passed to one or more mailboxes, semaphores provide a set of kernel- maintained counters, and shared memory provides some common pages that can be mapped in to each process's address space. Generally, shared memory is coupled with another type of IPC to coordinate updates to this common memory.

Some tuning is usually required if any user wants to make extensive use of these. The kernel includes basic IPC capabilities but they are limited in scope. The SunOS 4.x GENERIC configuration file includes these as options. If the system calls fail mysteriously, it is advisable as a first step to make sure that the options were not commented out or deleted in the kernel you are running.

Tunable parameters are defined (or at least listed) in the manuals. A description of the appropriate variables or values and their meanings is contained in each section below for the different IPC types. While these rarely appear in system panics, they can affect the behavior of user programs and the performance of the system. We've included a discussion of the kernel structures and variables to help analyze these problems.



PANIC. UNIX System Crash Dump Analysis Handbook
PANIC! UNIX System Crash Dump Analysis Handbook (Bk/CD-ROM)
ISBN: 0131493868
EAN: 2147483647
Year: 1994
Pages: 289
Authors: Chris Drake

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net