Brandeis University, Computer Science Department 146a

ASSIGNMENT 2: September 15th to September 21st, 2011

For Class Discussion: Monday September 19, 2011

In preparation of this meeting, read the paper on the X window system. The X window system was developed at MIT and is used all over the world including here at Brandeis. X is an excellent example of a well-designed system and demonstrates many of the system organization topics we will discuss in CS 146a. For this reading we ask you to do TWO things, complete a hands-on assignment and answer the following reading question:

One of the problems of Therac-25 system was a poorly designed UI. The company is hiring you to build a new UI on top of X Window System. Provide two clear benefits from use of X. Focus on technical merits of X (ignoring its ubiquity).
Not everybody is enamored by X. If you have some free time left on your hands after completing the hands-on (no pun intended), read "Myth: X Demonstrates the Power of Client/Server Computing" (pages 127-128) in The UNIX-HATERS Handbook for a different perspective on the X Window System.

For Lecture Material:

In the lecture we will continue with the material on enforcing modularity with clients and servers. This time we will consider a single machine. This material should be mostly familiar to you from cs31a. To refresh, review S&K Chapter 5.

For Class Discussion: Wednesday September 21st, 2011

We assume you are familiar with the thread abstraction and the primitives for thread sysnchronization from CS31a. Concurrency is important and complicated topic. Many of the hard-to-find bugs in programs are concurrency bugs, since often they are hard to reproduce. Race condition, a concurrency bug, was behind one of the Therac-25 accidents.

The next reading on the topic of enforcing modularity is therefore "Eraser: A Dynamic Data Race Detector for Multithreaded Programs" that deals with methodology and system support for avoiding race conditions. If you read this paper sequentially, you might not reach all the important issues. Skim over the section describing the Lockset algorithm. After you understand the main concepts of the paper, return to the Lockset algorithm. We do not expect you to memorize this algorithm. Rather, we expect you to learn about dealing with synchronization issues.

In Figure 2 of the paper, remember that "y:=y+1" is not necessarily atomic. First, the processor loads the value of y into a register. Next, the processor increments the register value. Finally, the value is written back to y. Can you find interleavings which result in different values of y? For your convenience, here are some useful definitions:

Static prevention
When all operations occur before execution to help prevent problems.
Dynamic detection
When operations occur during execution to help detect problems.
Bohr bug /bohr buhg/
Jim Gray calls a bug with a repeatable, deterministic behavior a Bohr bug (e.g., a program which always fails when you divide by zero).
heisenbug /hi:'zen-buhg/
Jim Gray calls a bug with non-deterministic (or timing dependent) behavior a heisenbug. These are particularly nasty bugs (e.g., a data race).

The Eraser paper refers to "static detection" rather than "static prevention". In dynamic detection, a program will try to catch errors when they happen, but will halt execution when errors arise. In static prevention, a program will try to catch errors before they happen -- preventing errors from happening in the first place.

Your reading report should briefly address the following questions:

According to the lockset algorithm, when does Eraser signal a data race? Why is this condition chosen? The paper talks about the false positives and false negatives answers provided by Eraser. What are they? When does each of them happen? Contrast their respective dangers.

For Lecture Material:

We are covering material that should be familiar to you from 31a. To review, read S&K Chapter 5, on enforcing modularity with clients and servers on a single machine.

System aphorism of the week
Everything should be made as simple as possible, but not simpler. (A. Einstein)

Assignment 2, issued 14/09/2011