Inter-process communication

Under inter-process communication (English inter - process communication, IPC ) refers to methods for information exchange, spoken informational table data transmission, of concurrent processes or threads. In a narrower sense is meant by IPC communication between processes on the same computer whose memory spaces but strictly separated ( memory protection ). In a broader sense IPC called but each data exchange in distributed systems, from threads that share a runtime system, to programs that run on different computers and communicate over a network.

While a suitable process synchronization is necessary for communication, especially when different processes can access the same resource at the same time potentially. Here, in addition to files, peripherals, etc also other processes that want to communicate, to be understood as resources. This is realized depending on the operating system or runtime environment and type of resource with locks, semaphores, monitors and the like. Classical problems of interprocess communication are the dining philosophers or the producer-consumer problem.

For the inter-process communication are depending on the operating system or runtime environment different methods are available:

Data streams

Data streams are communication channels, said data units ( single bytes or complex objects ) sequentially pass from one process to another. Of a process ( producer) writes data into the data stream, the other ( the consumer ) reads the data from the stream, it waits for new data to the producer provides it, or includes the current. Most of the power has an internal FIFO buffer, so that the producer can then write the data processed when the consumer just can not (or not fast enough). Only when this buffer is full, the producer has to wait when writing until the consumer has again taken from data ( or the communication breaks down in such a case with an error ).

The most common variant of this type of communication are so-called pipes, as they became popular through various Unix derivatives and are now supported by most operating systems. Pipes transmitted sequentially individual bytes. Each process are always two data streams assigned, one for output and one for input. An output power of a process can then be connected directly to the input stream of another process. If no explicit assignment made, the data streams are directly used for the communication with the user ( via a terminal ), ie, the input stream "reads" from the keyboard and output streams write on the screen.

An extension of this concept are Named Pipes is: These are not assigned to a process fixed, but can be just as it is written and read files. They exist as objects in the file system with a name, and thus offer a very flexible interface for communication with a process.

Also, connection-oriented network protocols (especially TCP) behave as data streams and can be used for inter-process communication ( also referred to as sockets). However, they have the advantage that one of them also can communicate with processes that are located on a different computer.

POSIX compatible operating systems do not distinguish between these three types of data streams: they are all accessed via a so-called file descriptor. Thus, the functions of a program do not know if they communicate via a pipe, a named pipe or a socket.

Although message queues, however, also function as data streams, but they have. Than basic unit arbitrarily complex messages instead of individual bytes They are much less prevalent.

A predecessor of the data streams, which is now used only in special cases, is the rendezvous, which can be thought of as a data stream without internal buffer. This therefore means that the producer can only write when the consumer is waiting on data, and vice versa, the consumer must always wait until the producer is delivering data. The result is that the two processes must "meet" for the transfer of data, hence the name.

Events

Some operating systems allow processes to respond to events in other processes - such events can also be understood as messages that a process sends another (see message exchange ). The processes must a subroutine as a handler for this event register, so it is always executed when the event occurs. This concept differs from the classical method from implementing programs as a linear sequence of commands - a clear program sequence, there are then only within the handler (see Inversion of Control ).

An example of this type of communication, which is also visible for the user is to use the clipboard a graphical user interface, the insertion of the process receiving the signal to transfer data from a buffer and insert it into a document.

The oldest version of this concept are software interrupts: these are called directly by the processor when an interrupt request is triggered either by a hardware component or by another process. Newer operating systems provide a flexible interface to register event handlers, for example with Windows DDE or Apple events from Apple.

Elements for process synchronization can itself be understood as a kind of event handling: Here, a process is waiting for an event (namely, the release of locks or semaphores ) that is triggered by another process. Some operating systems provide mechanisms to allow this across processes. Especially for accessing files are usually those mechanisms are available that can be used for synchronization of processes, without the content of the file is actually needed.

A special type of events are called the signals are used to control the process itself; especially to abort the process. For such signals, a process must not login explicitly, the operating system is causing many signals that the process reacts accordingly.

Function calls

The easiest way from a programming perspective access another process is to have such access to individual functions of the process, as if they were functions within the process - ie a method that makes it transparent to the programmer, where the implementation of a function is - in its own process or in another, which may be located on another computer even.

For many programming languages ​​there are such concepts, but they are usually not part of the runtime system or the operating system but can be provided by additional libraries and utilities (called middleware). The most common of such systems are the remote procedure call and the newer Remote Method Invocation (both from Sun Microsystems), DCOM ( Microsoft ), D -Bus ( from freedesktop.org ) DCOP ( KDE, now outdated and D-Bus replaced ) and CORBA.

Function calls are generally synchronous, blocking until the other process delivers a result. Asynchronous function calls are often implemented using futures, such as those offered as CORBA with the Asynchronous Method Invocation - but this is not usually without explicit implementation by the programmer possible. Some languages ​​integrate this concept but directly in the language itself, so as to allow transparent communication between threads.

Shared Memory

Another method for communication between programs is common memory. Here, areas of memory are reserved for access by multiple processes, where reading and writing is controlled by a mutex mechanism. The advantage is a fast transfer of large amounts of data, however, must be provided by an additional mechanism to ensure that the receiver process also learns when data are available for him. This often happens through a kind of event-handling or by cross-process semaphores or locks. To accesses to shared memory are algorithms for producer-consumer problem and the reader - writer problem for use. See also: deadlock.