@func{schedule} doesn't exist, which is arguably a @command{gdb} bug.
You can work around this by setting the breakpoint by filename and
line number, e.g.@: @code{break thread.c:@var{ln}} where @var{ln} is
-the line number of the first declaration in @func{schedule}.
-Alternatively you can recompile with optimization turned off, by
-removing @samp{-O3} from the @code{CFLAGS} line in
-@file{Make.config}.} Be sure to keep track of each thread's address
+the line number of the first declaration in @func{schedule}.} Be sure
+to keep track of each thread's address
and state, and what procedures are on the call stack for each thread.
You will notice that when one thread calls @func{switch_threads},
another thread starts running, and the first thing the new thread does
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.
+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
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 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
+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
interrupts in your solution by calling @func{intr_disable} or
@func{intr_set_level}, although you may find doing so to be useful
while debugging. Instead, use semaphores, locks and condition
-variables to solve synchronization problems. Hint: read the comments
+variables to solve synchronization problems. Read the tour section on
+synchronization (@pxref{Synchronization}) or the comments
in @file{threads/synch.h} if you're unsure what synchronization
primitives may be used in what situations.
could potentially be used more profitably by another thread. Your
solution should not busy wait.
-The argument to @func{timer_sleep} is expressed in timer ticks, not
-in milliseconds or another unit. There are @code{TIMER_FREQ} timer
+The argument to @func{timer_sleep} is expressed in timer ticks, not in
+milliseconds or any another unit. There are @code{TIMER_FREQ} timer
ticks per second, where @code{TIMER_FREQ} is a macro defined in
@code{devices/timer.h}.
+Separate functions @func{timer_msleep}, @func{timer_usleep}, and
+@func{timer_nsleep} do exist for sleeping a specific number of
+milliseconds, microseconds, or nanoseconds, respectively, but these will
+call @func{timer_sleep} automatically when necessary. You do not need
+to modify them.
+
+If your delays seem too short or too long, reread the explanation of the
+@option{-r} option to @command{pintos} (@pxref{Debugging versus
+Testing}).
+
@node Problem 1-2 Join
@section Problem 1-2: Join
@item
Examples of synchronization mechanisms have been presented in lecture.
Going over these examples should help you understand when each type is
-useful or needed.
+useful or needed. @xref{Synchronization}, for specific information
+about synchronization in Pintos.
@end enumerate
@item
@anchor{Out of Order 1-1}
This test is inherently full of race conditions. On a real system it
-wouldn't work perfectly all the time either. However, you can help it
-work more reliably:
+wouldn't work perfectly all the time either. There are a few ways you
+can help it work more reliably:
@itemize @bullet
@item
@item
Make the timer tick more slowly by decreasing @code{TIMER_FREQ} in
@file{timer.h} to its minimum value of 19.
-
-@item
-Increase the serial output speed to the maximum of 115,200 bps by
-modifying the call to @func{set_serial} in @func{serial_init_poll} in
-@file{devices/serial.c}.
@end itemize
The former two changes are only desirable for testing problem 1-1 and
possibly 1-3. You should revert them before working on other parts
-of the project or turn in the project. The latter is harmless, so you
-can retain it or revert it at your option.
+of the project or turn in the project.
@item
@b{Should @file{p1-1.c} be expected to work with the MLFQS turned on?}
projects / pintos-anon / blobdiff