CMPSCI 377 Operating Systems Spring 2009
Lecture 5: February 10
Lecturer: Mark Corner Scribes: Bruno Silva,Jim Partan
5.1 Processes
5.1.1 Unix process API
Re-visiting the Unix process API from the end of last lecture, is the sleep(1) call necessary to allow the
child process to start? The answer is no, it is not at all necessary. In general, if you think you need to sleep
in a program, you are probably doing something wrong, and just slowing down your program. The call to
waitpid() is a blocking wait, and will first wait to let the child process start (if it hasn’t already), then will
wait until it ends.
5.1.2 Interprocess Communication
Now we consider the following questions: how can the parent process communicate with its child? Or how can
children processes communicate with other children? The exact answer depends on the exact problem being
treated, but in general we call the several different approaches to this question by the name of Interprocess
Communication (IPC).
On possibility for IPC is to use sockets. This approach is based on explicit message passing, and has the
advantage that processes can be distributed anywhere on the Internet, among several different machines.
An application designed to use sockets can fairly easily be re-deployed as a multi-server application when its
needs outgrow a single server.
Another possibility is the use of mmap, which is a hack, although a very common one. Mmap uses memory
sharing as an indirect way of communicating. The way that this works is that all processes map the same
file into a fixed memory location. In this case, however, since we have objects being read from and written
to a shared memory region, we must use some kind of process-level synchronization. Unfortunately, these
synchronization procedures are in general much more expensive than the use of threads itself.
One can also use signals; in this case, processes can send and receive integer numbers associated with
particular signal numbers. In order to be able to receive and treat these numbers, processes must first set
up signal handlers. This approach works best rare events1. In general, signals are not very useful for parallel
or concurrent programming.
The other possibility is the use of pipes. These are unidirectional communication channels which make it
possible for the output of one program to be used as input to another one, just like in Unix (for example,
when we use the pipe symbol, as in “ls |wc -l”. The advantage of using pipes is that they are easy and fast.
1Example: pro cesses treating a SIGSEGV.
5-1
