Section 1.5. Interprocess Communication


1.5. Interprocess Communication

Processes communicate with one another by using one of several types of interprocess communication (IPC). With IPC, information transfer or synchronization occurs between processes. Solaris supports four different groups of interprocess communication: traditional (basic) IPC, System V IPC, POSIX IPC, and advanced Solaris IPC.

1.5.1. Traditional UNIX IPC

Solaris implements the traditional UNIX IPC facilities: pipes, named pipes, and UNIX domain sockets.

A pipe directly channels data flow between two related processes through an object that operates like a file. Data is inserted at one end of the pipe and travels to the receiving process in a first-in, first-out order. Data is read and written on a pipe with the standard file I/O system calls. Pipes are created with the pipe(2) system call.

Named pipes, also commonly known as FIFOs (which stands for first-in, first-out, the method of data movement in named pipes), are implemented as a file in the file system namespace. As such, it is easier to use FIFOs to connect processes that are not related. FIFOs are implemented with the mkfifo(3C) interface.

A socket is a file-like abstraction that provides a communication endpoint between processes. The communication can be over a network (a network domain socket) or a UNIX domain (local) socket. A local socket is a network-like connection using the socket(2) system call to directly connect two processes.

1.5.2. System V IPC

Three types of IPC originally developed for System V UNIX have become standard across all UNIX implementations: shared memory, message passing, and semaphores. These facilities provide the common IPC mechanism used by the majority of applications today.

  • System V Shared Memory. Processes can create a segment of shared memory. Changes within the area of shared memory are immediately available to other processes that attach to the same shared memory segment.

  • System V Message Queues. A message queue is a list of messages with a head and a tail. Messages are placed on the tail of the queue and are received on the head. Each messages contains a 32-bit type value, followed by a data payload.

  • System V Semaphores. Semaphores are integer-valued objects that support two atomic operations: increment or decrement the value of the integer. Processes can sleep on semaphores that have a value of zero, then can be awakened when the value becomes greater than zero. Semaphores are really more a synchronization facility than an interprocess communication facility.

Setting kernel tunable parameters for System V IPC is extremely common in Solaris environments. It is rare to examine an /etc/system file on a Solaris system that does not have entries for System V IPC resource allocation. In Solaris 10, a significant amount of work went into reducing the need to tune IPC values, and the tuning method itself has changed. Most of the traditional tunable parameters are now obsolete, and those that remain have much larger default values. Should it be necessary to change a value from its default in Solaris 10, the method for changing these values involves the use of new resource control facilities. See Section 4.2 for information about using the prctl(1) and rctladm(1) commands for changing IPC values.

Other IPC tunable parameters not listed in the table are obsolete. If obsolete parameters appear in the /etc/system file in Solaris 10, they are ignored.

1.5.3. POSIX IPC

The POSIX IPC facilities are similar in functionality to System V IPC but are very different in their implementation. Whereas the System V IPC facilities are kernel-maintained objects, POSIX IPC objects are abstracted on top of memory mapped files. The POSIX library routines are called by a program to create a new semaphore, shared memory segment, or message queue. Internally, Solaris file I/O system calls (open(2), read(2), mmap(2), etc.) are used because the IPC objects exist as memory mapped files. The object type exported to the program through the POSIX interfaces is handled within the files. The object type exported to the program through the POSIX interfaces is handled within the library routines.

1.5.4. Solaris Doors: Advanced Solaris IPC

Solaris Doors are a new, fast, lightweight mechanism for calling procedures between processes. Doors are a low latency method of invoking a procedure in a different process on the same system. A door server contains a thread that sleeps, waiting for an invocation from the door client. A client makes a call to the server through the door, along with a small (16-Kbyte) payload. When the call is made from a door client to a door server, scheduling control is passed directly to the thread in the door server. Once a door server has finished handling the request, it passes control and response back to the calling thread. The scheduling control allows ultra-low-latency turnaround because the client can complete the request without waiting for the server thread to be scheduled.




SolarisT Internals. Solaris 10 and OpenSolaris Kernel Architecture
Solaris Internals: Solaris 10 and OpenSolaris Kernel Architecture (2nd Edition)
ISBN: 0131482092
EAN: 2147483647
Year: 2004
Pages: 244

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