Another natural question can be, can processes interact?
And the simple answer to this is yes.
An operating system must provide mechanisms to allow processes to
interact with one another.
And today in fact, more and
more of the applications we see are actually structured as multiple processes.
So these multiple processes have to be able to interact to contribute to
a common goal of a more complex multi-process application.
For instance, here's an example of a web application consisting of
two processes on the same machine.
The first one is the web server,
the front-end, that accepts the customer request.
And the second one is the backend,
the database that stores customer profiles and other information.
This is a very common case in many enterprise and web applications.
So, how may these processes interact?
Now, before we answer that, remember that the operating systems
go through a great deal to protect and isolate processes from one another.
Each of them is a separate address space.
They control the amount of CPU each process gets,
which memory is allocated, and accessible to each process.
So these communication mechanisms that we will talk about somehow have to be
built around those protection mechanisms.
These kinds of mechanisms are called inter-process communication mechanisms, or
we refer to them as IPC.
The IPC mechanisms help transfer data and information from one
address space to another, while continuing to maintain the protection and
isolation that operating systems are trying to enforce.
Also, different types of interactions between processes may
exhibit different properties.
Periodic data exchanges, continuous stream of data flowing between the processes
or coordinated at the, to some shared single piece of information.
Because of all these differences,
IPC mechanisms need to provide flexibility as well as clearly performance.
One mechanism that operating systems support is message passing IPC.
The operating system establishes a communication channel,
like a shared buffer for instance, and the processes interact with it
by writing or sending a message into that buffer.
Or, reading or receiving a message from that shared communication channel.
So, it's message passing because every process has to put the information that
it wants to send to the other process, explicitly in a message and
then to send it to this dedicated communication channel.
The benefits of this approach is that it's really the operating system who will
manage this channel, and it's the operating system that provides the exact same
APIs, the exact same system calls for writing or
sending data, and the reading or receiving data from this communication channel.
The downside is the overhead.
Every single piece of information that we want to pass between these two
processes we have to copy from the user space of the first
process into this channel that's sitting in the OS, in the kernel memory.
And then back into the address space of the second process.
The other type of IPC mechanism is what we call shared memory IPC.
The way this works is the operating system establishes the shared
memory channel, and then it maps it into the address space of both processes.
The processes are then allowed to directly read and write from this memory, as
if they would to any memory location that's part of their virtual address space.
So the operating system is completely out of the way in this case.
That in fact is the main advantage of this type of IPC.
That the operating system is not in the fast path of the communication.
So the processes, while they're communicating are not going to incur any kind of
overheads from the operating system.
The disadvantage of this approach is because the operating system is out of
the way it no longer supports fixed and
well defined APIs how this particular shared memory region is used.
For that reason, its usage sometimes becomes more error prone, or
developers simply have to re-implement code to use this
shared memory region in a correct way.