-@node Debugging versus Testing
-@section Debugging versus Testing
-
-When you're debugging code, it's useful to be able to be able to run a
-program twice and have it do exactly the same thing. On second and
-later runs, you can make new observations without having to discard or
-verify your old observations. This property is called
-``reproducibility.'' The simulator we use, Bochs, can be set up for
-reproducibility, and that's the way that @command{pintos} invokes it
-by default.
-
-Of course, a simulation can only be reproducible from one run to the
-next if its input is the same each time. For simulating an entire
-computer, as we do, this means that every part of the computer must be
-the same. For example, you must use the same disks, the same version
-of Bochs, and you must not hit any keys on the keyboard (because you
-could not be sure to hit them at exactly the same point each time)
-during the runs.
-
-While reproducibility is useful for debugging, it is a problem for
-testing thread synchronization, an important part of this project. In
-particular, when Bochs is set up for reproducibility, timer interrupts
-will come at perfectly reproducible points, and therefore so will
-thread switches. That means that running the same test several times
-doesn't give you any greater confidence in your code's correctness
-than does running it only once.
-
-So, to make your code easier to test, we've added a feature, called
-``jitter,'' to Bochs, that makes timer interrupts come at random
-intervals, but in a perfectly predictable way. In particular, if you
-invoke @command{pintos} with the option @option{-j @var{seed}}, timer
-interrupts will come at irregularly spaced intervals. Within a single
-@var{seed} value, execution will still be reproducible, but timer
-behavior will change as @var{seed} is varied. Thus, for the highest
-degree of confidence you should test your code with many seed values.
-
-On the other hand, when Bochs runs in reproducible mode, timings are not
-realistic, meaning that a ``one-second'' delay may be much shorter or
-even much longer than one second. You can invoke @command{pintos} with
-a different option, @option{-r}, to make it set up Bochs for realistic
-timings, in which a one-second delay should take approximately one
-second of real time. Simulation in real-time mode is not reproducible,
-and options @option{-j} and @option{-r} are mutually exclusive.
-
-@node Tips
-@section Tips
-
-@itemize @bullet
-@item
-There should be no busy waiting in any of your solutions to this
-assignment. We consider a tight loop that calls @func{thread_yield}
-to be one form of busy waiting.
-
-@item