Inter Process Communication (IPC) Basics
When running an Operating System in our system weather it is Real time OS or general-purpose OS (like Linux style), the user application will be divided into multiple tasks and each tasks will be divided into threads.
In general-purpose OS like Linux the different tasks/process will execute in logical address space which can be shared by all those tasks but due to the existence of address space translation from virtual to physical address, each process in reality has its own physical address space. This isolation in term of physical address space will create certain challenges when it comes to communicate certain information back and forth between different process running on top of the general-purpose OS.
The same challenge is applicable for tasks running on top of real time OS, as this one as well although doesn’t has this address space translation between logical and physical one (system executing Real time OS has only physical address space) will need to isolate each process address space from other process leading to difficulty to establish communication and information sharing between different tasks.
This information and message sharing is not big deal when it comes to threads, as thread per definition are executing in same physical address space, means they share the same process physical address space, so creating small area within that address space for information/messages sharing between threads should resolve the issue of inter-threads communication.
For Process as they don’t share the same physical address space as we have discussed, there were different methods has been elaborated to establish what is so called Inter-Process-Communication or IPC, below some of the well known mechanism to communicate data/messages between different running tasks/processes:
- Pipes
- Queue
- Shared Memory
- Mailbox
Pipes
Pipe is created between two processes that share the same parent, so Pipe cannot be used between any two process, there be should some parent relationship between both processes. Pipes are not broadcasted based communication and can be used only between the two child-processes.
Pipe is used to communicate stream of data not formatted or structured, therefore to specify the separation between one stream of data and another it is the responsibility of the processes to agree on how to specify the end of each stream of data.
The maximum size of communicated data over pipe between 2 child process is 4 kb, and the communication is unidirectional between the two process, it is similar to simplex mode communication where data flow is in single direction, in this case one process will be writing the data and will get blocked until the other process read the data from the pipe, so we are talking here about synchronous based communication where one process will be blocked until the other process finish reading and pipe after that can be released.
Although Pipe based inter process communication is quiet efficient in term of performance as it doesn’t involve the overhead of system calls invocation to switch to kernel space for services request, but it does has some big limitation when it comes to how many process it can be used with which is limited to only child-related processes, also cannot be used easily between processes running on different systems , not like indirect messaging using Queue and mailbox where processes can be distributed in different systems.
Queue
Queue by itself is memory space part of the kernel and fully managed by the kernel itself, so requesting space on the queue where the process message to be stored will need to go through the kernel services request (using System calls), from this point we can understand that queue has performance overhead drawback compared to pipe mechanism.
However, queue doesn’t have the child-relationship processes limitation, queue can be used with one-to-many topology, meaning the master process will create single queue for communication with multiple processes and provide services to multiple processes through the queue, this topology can be deployed on Pub-Sub model (Publisher-Subscribers model).
Queue is bidirectional (contrarily to pipe which is unidirectional), the data can flow in both directions. The communication using queue can be synchronous or asynchronous , synchronous means the producer process will wait until the consumer process finish reading the message, or asynchronous and in that case the producer process will place the message into the queue then move in execution without waiting for consumer process to read the message.
The message to be placed in the queue can go up to 8 kb.
Queue can be bounded and unbounded, bounded means queue will have predefined size and sender will need to check that queue still has some space for new message (the receiver in any case will need to check that the queue is not empty and has available message to read), unbounded means the queue will have unlimited size and the producer process doesn’t need to check if the queue still have a space for new message or not.
Shared memory
Shared memory will be allocated by the kernel to be accessible by different process, the access to shared memory is not managed by the kernel, it is fully under the control of different process. Although this eliminate the overhead due to kernel context switching in the case of queue but in the other hand the access management to shared memory should be under the responsibility of the different processes. Processes in Producer/Consumer problem will add mechanism to synchronize access to messages within shared memory using for instance semaphores.
Shared memory as method is quiet efficient for raw data transfer by eliminating any system calls invocation.
Mailbox
mailbox is similar to queue in the sense that is based on data structure used to store messages to be communicated from one process to another.
Process like in queue will address the message to the mailbox object, then later the consumer process will retrieve the message from the mailbox when needed.
The advantage of mailbox in regard to queue is when having multiple processes/threads, mailbox has set of built-in semaphores to address issues of having multiple process/threads accessing mailbox message in the same time, this is not possible with queue unless you implement manually such protection mechanism against concurrent processes/threads access which is little bit of hassle to be done by the user, so using already available objects with such mechanism like in mailbox is big advantage.
The drawback with mailbox and semaphores built-in mechanism is performance compared, so the usage of mailbox is recommended for design where you will have multiple processes/threads accessing concurrently messages stored in mailbox.
Conclusion
The choice of which communication method to use between different processes is matter of use case not matter of which one is the best.
However some criteria that can helps us to choose the suitable method for our use case can be either:
- Latency: the producer process will need to write the message to the communication interface as fast as possible to move the execution and save for the consumer process which needs to retrieve the message without big overhead.
- Bandwidth: the producer process will requires to send big chunk of data to the consumer via the IPC interface, so the IPC will need to provide the required bandwidth for data transfer between different processes.
- Data Loss rate: during inter-process communication, there may some data loss involved specially when big amount of data get transferred between different processes, and synchronization mechanism between producer/consumer is not robust enough to prevent data loss. IPC method to be used can impact significantly the loss rate in relation to the use case.
