Week 9 - Inter-process communication
Inter-process communication (IPC)
Link to originalInter-process communication (IPC)
Inter-process communication is the method or API in which different processes can communicate with one another. There are four main methods to communicate messages between two processes.
- Message-passing IPC: This is via the OS which offers an API to pass messages between processes the OS puts them on a message bus that is sent to the other process. This has the advantage that it is managed by the OS and is safe - though it has the disadvantage of needing the OS which incurs a lot of overhead.
- Shared memory IPC: This lets two processes share some physical memory which is mapped into both their virtual memory space. This means the OS is out of the way but the two processes must know how to use that shared memory with one another - sometimes having to re-implement code in the OS.
- Higher level semantics: Such as shared files or Remote Procedure Calls (RPC).
- Synchronization: Methods in which two processes can synchronize so not to adversely effect one an others operation. Examples are mutexes or semaphores.
Message based IPC
Message based IPC opens two ports (not necessarily in the networking sense) one in each process. Then the kernel is used to move the messages between the two ports. Examples of this are:
- Pipes: A stream of bytes between the process - no structured messages. This is used when connecting stdin to stdout of a process when you ‘pipe’ them in a terminal.
- Message queues: A queue of structured messages that the processes can pop one at a time. In linux there two APIs for this SystemV and POSIX.
- Network sockets: Uses the same interface as connecting to a network port. Normally the operating system optimizes this process by skipping some overhead of the network protocols. Message based IPC is simple to use as the kernel handles the synchronization but come with overhead as the message has to be copied between processes and involves context switches to communicate with the kernel.
Shared Memory IPC
This form of IPC maps a bit of memory into both processes. After it is mapped in neither processes need to go through the kernel to communicate. However that means both processes need synchronization to ensure they don’t over-write one another. They also need to establish a shared protocol on how to communicate.
The main APIs here are: SystemV and POSIX.
SystemV shared memory
- Uses “segments” of shared memory which are not necessarily contiguous physical memory.
- The memory is shared system wide. This means there are system wide limits on shared memory.
- The operating system creates a shared memory segment and identifies it by a key.
- Processes need to map that physical memory into their virtual memory.
- This segment can be detached (so it no longer has a mapping in virtual memory).
- The segment can also be destroyed so it no longer has a system identifier.
In comparison to SysV POSIX uses a shared file descriptor to access the shared memory.
Synchronization
As multiple processes can now access the same memory we need to be able to coordinate read and writes.
Pthreads mutexes and conditional variables can be used for this but we will need to share their data structures in the shared memory to be accessed by both processes.
This can also be achieved via a message queue by sending read write messages.
Otherwise semaphores can be used for this which will be covered later.
Command line utility with IPC
When using SysV you can use the following command line functions to manage IPC resources:
- ipcs: This is used to display information about the utilities. The -m flag displays information on shared memory only.
- ipcrm: This deletes IPC entities. You can specify an exact one using the -m flag with the shmid.
When using the POSIX API the IPC tools are saved as files and can be accessed via:
- /dev/shm: For shared memory and semaphores.
- /dev/mqueue: For shared queues.
Design considerations
When using shared memory, you can choose between one large segment of shared memory for two processes or lots of smaller segment for each purpose.