# Homework: Locking

Read: spinlock.c

Hand-In Procedure

You are to turn in this homework at the beginning of lecture. Please write up your answers to the exercises below and hand them in to a 6.828 staff member at the beginning of lecture.

Assignment: In this assignment we will explore some of the interaction between interrupts and locking.

Make sure you understand what would happen if the kernel executed the following code snippet:

      struct spinlock lk;
      initlock(&lk, "test lock");
      acquire(&lk);
      acquire(&lk);

(Feel free to use Bochs to find out. `acquire` is in `spinlock.c`.)

An `acquire` ensures interrupts are off on the local processor using `cli`, and interrupts remain off until the `release` of the last lock held by that processor (at which point they are enabled using `sti`).

Let's see what happens if we turn on interrupts while holding the `ide` lock. In `ide_rw` in `ide.c`, add a call to `sti()` after the `acquire()`. Rebuild the kernel and boot it in Bochs. Chances are the kernel will panic soon after boot; try booting Bochs a few times if it doesn't.

Turn in: explain in a few sentences why the kernel panicked. You may find it useful to look up the stack trace (the sequence of `%eip` values printed by `panic`) in the `kernel.asm` listing.

Remove the `sti()` you added, rebuild the kernel, and make sure it works again.

Now let's see what happens if we turn on interrupts while holding the `kalloc_lock`. In `kalloc()` in `kalloc.c`, add a call to `sti()` after the call to `acquire()`. You will also need to add `#include "x86.h"` at the top of the file after the other `#include` lines. Rebuild the kernel and boot it in Bochs. It will not panic.

Turn in: explain in a few sentences why the kernel didn't panic. What is different about `kalloc_lock` as compared to `ide_lock`?

You do not need to understand anything about the details of the IDE hardware to answer this question, but you may find it helpful to look at which functions acquire each lock, and then at when those functions get called.

(There is a very small but non-zero chance that the kernel will panic with the extra `sti()` in `kalloc`. If the kernel does panic, make doubly sure that you removed the `sti()` call from `ide_rw`. If it continues to panic and the only extra `sti()` is in `bio.c`, then mail 6.828-staff@pdos.csail.mit.edu and think about buying a lottery ticket.)

Turn in: Why does `release()` clear `lock->pcs[0]` and `lock->cpu` before clearing `lock->locked`? Why not wait until after?