CS360 Final Exam - Answers and Grading

The exam was given on Canvas with banks used for some questions. These explanations apply to the example exam, plus I give answers to the other bank questions.

Question 3 (25 points)

• How many bytes are in the heap (allocated and unallocated)? The heap starts at address 0x7000 and sbrk(0) returns 0x7248, so the answer is 0x248 = 512 + 64 + 8 = 584 bytes. Either answer is fine. (3 points)

• How many total bytes are on the free list? The first node on the free list starts at 0x7100. The first four bytes there contain the size of the free chunk: 0x50 = 80 bytes. The second four bytes are the flink pointer, which is zero. So that's the only free chunk. The answer is 0x50 or 80. (3 points)

• What is the minimum number of allocated chunks in the heap? The first allocated chunk on the free list is at address 0x7000. The first four bytes there contain the size of the chunk: 0x100 bytes. That means the first chunk goes all the way to the first free chunk. The second chunk starts at address 0x7150, and since we're not told what value is there, we don't know how big it is. However, its value could be 0xf8, which means it could go to the end of the heap. In that case, there are two allocated chunks. The answer is two. (2 points)

• What is the maximum number of allocated chunks in the heap? The smallest allocated chunk size is 16 bytes: 8 for the data and 8 for bookkeeping. Since there are 0xf8 bytes after the free chunk, that can be 0xe = 14 chunks: 13 which are 0x10 = 16 bytes, and one that is 0x18 = 24 bytes. That makes a total of 15 chunks, including the first one. (2 points)

  The value of 0x248 at address 0x7200 feels problematic - it can't be a legal size, so it should be data. That doesn't change our answer -- if the first chunk is 24 bytes, and then the rest are 16 bytes, then 0x7200 is data, and its value of 0x248 doesn't matter.

• What will be the value of i when I generate a segmentation violation? Since sbrk(0) returns 0x7248, we know that address 0x7247 won't generate a segmentation violation. Pages are 4K, so the first address to generate a segmentation is the first multiple of 4K above 0x7248. 4K is 0x1000, so that address is 0x8000. So the answer is (0x8000 - 0x7200). You can calculate it if you want: 0xe00 = 3584. The arithmetic expression is easier to use...

  (2 points)

• Suppose that we have the minimum number of allocated chunks in the heap. What is the smallest value of x for which malloc(x) will require us to call sbrk()? The number of allocated chunks doesn't matter. There's one free chunk whose size is 0x100. If I call malloc(0xf9), then I'll need a chunk of size 0x108. The answer is 0xf9, or 249.

• When we call free(0x7208), we are going to free the chunk that starts at 0x7200. Its size is 0x248, which looks like a real problem, but free() doesn't care. It will simply put the chunk on the free list:
  1. That chunk will be on the head of the free list, so the value at address 0x6200 changes to 0x7200.
  2. We need to set the chunk's flink pointer to point to the old head of the free list, so the value at address 0x7204 changes to 0x7100.
  3. We need to set the chunk's blink pointer to point to NULL, so the value at address 0x7208 changes to 0x7100.
  4. We need to set the blink pointer of the other chunk in the free list, so the value at address 0x7108 changes to 0x7200.

  Each of these address-value pairs is worth three points.

Question 4 (25 points)

• What are the potential outputs to: ./a.out PP P? Each thread calls pthread_mutex_lock() when it starts, and pthread_mutex_unlock() when it finishes, so whichever thread gets control first will do its printing, and then exit, and then the other thread will go. So there are two outputs, depending on which thread gets control first:

  AAB BAA

• What are the potential outputs to: ./a.out P P PE? The key here is that once thread C gets the mutex, it will print its id and then call exit(). That kills the process, including the other two threads. So the answers are:

  ABC AC BAC BC C

• What are the potential outputs to: ./a.out XP XP SPAA? The first thing to note is that thread C sleeps. So the other two call pthread_cond_wait() on cv1. When thread C wakes up, it prints its id, and then calls pthread_cond_signal() twice. One of those calls wakes up thread A and the other thread B. So each of them will print their id. We don't know in what order threads A and B block themselves, or in what order they are awakened by thread C. So there are two possible outputs:

  CAB CBA

• What are the potential outputs to: ./a.out SPAB XP YP P? This is very similar to the previous call, but with two differences: Threads B and C are waiting on different condition variables, and there is a thread D that prints its id instantly. So the output will start with D, and then A, and even though thread A calls pthread_cond_signal() first on cv1, we don't know in what order the two threads will unblock themselves and reacquire the mutex. The answer is:

  DABC DACB

• What are the potential outputs to: ./a.out SPA XPA XPA? Threads B and C block, while thread A sleeps a second. It then prints its id and signals one of the threads. We don't know which. Whichever wakes up first prints its id and then wakes up the other thread. So, again, two outputs:

  ABC ACB

• What are the potential outputs to: ./a.out PXP SABP PYP? Threads A and C instantly print their ids, in any order. Thread A blocks on cv1 and thread C blocks on cv2. Thread B waits a second, signals both cv's and prints its id. That happens before threads A and C can reacquire the mutex. When they do, they print their id's. There's no ordering between threads A and C, either before the blocking or after, so there are four potential outputs:

  ACBAC ACBCA CABAC CABCA

• What are the potential outputs to: ./a.out SPAB XPYP SPAB? Threads A and C sleep, while thread B waits on cv1. Whichever thread wakes up first calls pthread_cond_signal() on cv1 and then cv2. Both while holding the mutex. That will wake up thread B, and if it gets the mutex first, it will print, then block on cv2. The other thread will then get the mutex, print, and signal both cv1 and cv2. That will wake thread B up again, and it will print and exit. The outputs will be either: "ABCB" or "CBAB".

  However, there's a chance that the "other" thread will get the mutex before thread B, in which case it signals both cv's, which at this point have no blocked threads. Thread B will finally get the mutex, print, and block on cv2, never to wake up. The outputs will be either "ACB" or "CAB". So the answer is:

  ABCB ACB CAB CBAB

Grading

Question 5 (25 points)

• The first program opens f1.txt for writing, then writes one line. It calls fork(), so now there are two processes sharing the same open file. Each writes a line, so the file ends up with three lines. The answer is 3.

• The second program opens f1.txt as a stdio stream, so the first fprint() copies the line to a buffer in memory. After the fork() call, each process has its own copy of the buffer, and copies another line there, so both buffers have two lines. When they call fclose() the lines are flushed to the file, so the file has four lines. The answer is 4.

• The third program ends up with 16 processes, each of which prints a line, so the answer is 16.

• ./a.out 6 1 1 y: The parent sleeps for 6 seconds. The two children sleep for one secone, then call fwrite() 100 times for a total of 400 bytes. The fwrites() are buffered in the children's stdio buffers, and the children then return. That causes the two buffers to be flushed with two write() calls (one write() per child), and the amount of data is small enough that it will be stored in the pipe buffer in the operating system. When the parent wakes up, it does 200 fread() calls, but there will only be one read() calls, because the 800 bytes are in the pipe buffer. The answer is one.

• ./a.out 0 1 4 n: The parent starts first, and its fread() will call read(). That blocks. The first child wakes up a second later and writes 400 bytes to the pipe buffer. The parent wakes up and reads the 400 bytes and exits. When the second child wakes up and calls fwrite(), the other two processes are dead, so when it flushes the buffer, it can generate SIGPIPE. Will it? You never know, because sometimes the operating system buffers the write, but all of the conditions are there to generate SIGPIPE. The answer is Y.

• Making a zombie. Let's consider the possibilities. In this, p = the parent's sleep time, c1 = the first child's sleep time, c2 = the second child's sleep time, and l = the last argument. Obviously, in all of these you can switch the identities of c1 and c2:
  • p == c1 (or p == c2): Nothing is forced here. In particular, the two child can write, and the parent can read, and the operating system has it all done before it lets any of them return. They can then exit in any order.
  • p > c1 (or p > c2). The child exits before the parent, and it becomes a zombie.
  • p < c1 (or p < c2). This is like the first case -- when the child writes, the operating system will complete the parent's read and they can both return.

  So the answer needs to have the parent's sleep time to be greater than at least one child.

• ./a.out 0 1 3 y: When the first child writes its bytes and exits, the parent's read() will return with 400 bytes, and its first 100 freads() will be satisfied. It will try read() again. Two seconds later, the second child writes its bytes and exits, and now the parent's read() call returns. The answer is two.

• ./a.out 10 2 2 n: Each child writes once (as in "6 1 1 y") above. The answer is two.

• ./a.out 3 1 0 n: By the time the parent wakes up, both children have written their bytes into the buffer and have exited. There is no SIGPIPE: N.

• ./a.out 8 0 0 n: The answer is Y. Both children flush their stdio buffers, making write() calls of 400 bytes each. Those will be performed serially by the operating system, so the pipe buffer will contain the numbers from 0 to 99 in order twice.

• Making an orphan. Let's consider the possibilities:
  • p == c1 == c2: As above, nothing is forced here.
  • l = y. The parent won't exit before the second child is done writing, so as in the previous case, nothing is forced.
  • p > c1 (or p > c2). The child exits before the parent, and it becomes a zombie, not an orphan.
  • p < c1, c1 = c2, l=n. Again, the children exit at the same time as the parent -- no orphan.
  • c1 > p and c1 > c2, l=n. Now the parent exits with child 2, and child 1, which is sleeping, becomes an orphan.

Question 6 (25 points)

int start_ga(int seed)
{
  int pid;
  int p[2];
  int fd;
  char buf[20];

  /* You can call pipe() before fork(), and have the parent write the
     seed to the child, but it's easier to have the child write to the pipe. */

  pid = fork();

  if (pid == 0) {
    pipe(p);                        /* Only call pipe() in the child */
    sprintf(buf, "%d\n", seed);     /* Write the seed -- it will go to the buffer in the OS. */
    write(p[1], buf, strlen(buf));
    close(p[1]);
  
    sprintf(buf, "f%03d.txt", seed);                   /* Create the output file and have it */
    fd = open(buf, O_WRONLY | O_CREAT | O_TRUNC, 0666);/* go to stdout */
    dup2(fd, 1);
    close(fd);

    dup2(p[0], 0);                  /* Stdin comes from the pipe */
    close(p[0]);
    execlp("./ga", NULL);           /* Execute the program. */
    perror("execlp");
    exit(1);
  }
  return pid;
}

And here's kill_slow()

void kill_slow(JRB pids)
{
  JRB tmp;
  long t0;

  /* Traverse the tree and kill old processes. */

  t0 = time(0);
  jrb_traverse(tmp, pids) {
    if (tmp->val.l + TIMEOUT <= t0) {
      kill(tmp->key.i, SIGKILL);
    }
  }
}

Part 2: There are two answers. The easy one is to call alarm(3600) in the child process right before it calls execlp(). If the child doesn't handle the alarm, it will kill the process at the right time.

The truly proper way to do this is to have kill_slow() calculate when the next process should be terminated, and call alarm() for that time. Each alarm() call cancels the previous one, which is why you have to figure out the soonest process to kill each time you call alarm(). Have the alarm handler call kill_slow(). You don't need to have the code, but here it is:

void kill_slow(JRB pids)
{
  JRB tmp;
  long t0;
  int min;

  min = TIMEOUT+1;
  t0 = time(0);
  jrb_traverse(tmp, pids) {
    if (tmp->val.l + TIMEOUT <= t0) {
      kill(tmp->key.i, SIGKILL);
    } else {
      if (tmp->val.l + TIMEOUT - t0 < min) min = tmp->val.l + TIMEOUT - t0;
    }
  }
  if (min == TIMEOUT+1) min = 0;
  alarm(min);
  signal(SIGALRM, handler);
}

void handler(int dummy)
{
  kill_slow();
}

Grading:

• 5 points for kill_slow()
• 5 points for describing how to use SIGALRM and alarm() correctly.
• 5 points for setting up the output file for the child.
• 5 points for setting up the pipe correctly and writing the seed to it.
• 5 points for fork/exec/cardinal sin.