Lecture 4: Inter-process Communication

2 September, 2011

This is the first of a two-lecture series on inter-process communication (IPC). You will learn about share memory and message passing as two generic methods for IPC, and learn about signals and pipes, two communication abstractions on UNIX. We will then discuss the complexities that arise from sharing of resources between two processes (or two threads), and cover the concepts of race conditions, mutual exclusion, critical regions, and consider various methods to ensure mutual exclusion (including test-and-set, peterson’s algorithm, and disabling interrupts).

Having a hardcopy of slides during lecture would be helpful. Be prepare to take notes during lecture.

Download Slides: PDF

Reading:

  • Section 2.3 (up to and include 2.3.4)

Related Wikipedia entries are listed below. These are for students who are keen to go beyond what is covered in CS2106. Read the articles with a critical mind since Wikipedia is editable by anyone.

Here are related man pages: kill | signal

4 thoughts on “Lecture 4: Inter-process Communication

  1. During the lecture, the professor mentioned that the statement:
    while (loop) { … }
    is another way of saying:
    while (loop == 1) { … }

    This is technically incorrect. Instead, it is another way of saying:
    while (loop != 0) { … }

    • @Jonathan,

      You are right.

      while(loop) is equivalent to while (loop != 0) in general.

      In the example, however, the lock variable can only be either 1 or 0.

  2. You mentioned that the signals for a process are queued and they will be de-queued and its signal handlers are ran one after another in a FIFO manner when the process changes from a ready to run state. So does this imply that in a blocked state, the process doesn’t catch any signals and run their signal handlers at all? Hmm, I’m kinda confused about this because it seem to imply that I can’t kill a blocked process…

    • Great question.

      SIGSTOP and SIGKILL are exceptions and had to be delivered by kernel right away. This is important for runaway processes to be killed.

Comments are closed.