INTERPROCESS
COMMUNICATION
Shilpi Sanyal
Need for Interprocess Communication?
Processes frequently need to communicate with other processes. For
example, in a shell pipeline, the output of the first process must be passed to
the second process, and so on down the line. Thus there is a need for
communication between processes, preferably in a well-structured way not
using interrupts.
3 issues:
• How one process passes information to the other
• How to make sure two or more processes do not get in each other’s way
• How to do proper sequencing when dependencies are present
Race Conditions
In some operating systems, processes that are working together may share
some common storage that each one can read and write. The shared storage
may be in main memory (possibly in a kernel data structure) or it may be a
shared file; the location of the shared memory does not change the nature of
the communication or the problems that arise.
When a process wants to print a file, it enters
the file name in a special spooler directory.
Another process, the printer daemon,
periodically checks to see if there are any
files to be printed, and if there are, it prints
them and then removes their names from the
directory.
Critical Regions
How do we avoid race conditions? The key to preventing trouble here and in
many other situations involving shared memory, shared files, and shared
everything else is to find some way to prohibit more than one process from
reading and writing the shared data at the same time. Put in other words,
what we need is mutual exclusion, that is, some way of making sure that if
one process is using a shared variable or file, the other processes will be
excluded from doing the same thing.
However, sometimes a process has to access shared memory or files, or do
other critical things that can lead to races. That part of the program where
the shared memory is accessed is called the critical region or critical
section.
Although this requirement avoids race conditions, it is not sufficient for
having parallel processes cooperate correctly and efficiently using shared
data. We need four conditions to hold to have a good solution:
1. No two processes may be simultaneously inside their critical regions.
2. No assumptions may be made about speeds or the number of CPUs.
3. No process running outside its critical region may block any process.
4. No process should have to wait forever to enter its critical region.
Mutual Exclusion while Busy Waiting
Various proposals for achieving mutual exclusion, so that while one process
is busy updating shared memory in its critical region, no other process will
enter its critical region and cause trouble.
1. Disabling Interrupts
On a single-processor system, the simplest solution is to have each
process disable all interrupts just after entering its critical region and re-
enable them just before leaving it. With interrupts disabled, no clock
interrupts can occur. The CPU is only switched from process to process as a
result of clock or other interrupts, after all, and with interrupts turned off the
CPU will not be switched to another process. Thus, once a process has
disabled interrupts, it can examine and update the shared memory without
fear that any other process will intervene.
2. Lock Variables
Consider having a single, shared (lock) variable, initially 0. When a
process wants to enter its critical region, it first tests the lock. If the lock is 0,
the process sets it to 1 and enters the critical region. If the lock is already 1,
the process just waits until it becomes 0. Thus, a 0 means that no process is
in its critical region, and a 1 means that some process is in its critical region.
3. Strict Alternation
4. Peterson’s Solution
5. The TSL Instruction