Using the @command{gdb} debugger, slowly trace through a context
switch to see what happens (@pxref{i386-elf-gdb}). You can set a
breakpoint on the @func{schedule} function to start out, and then
-single-step from there. 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 is to return from
-@func{switch_threads}. We realize this comment will seem cryptic to
-you at this point, but you will understand threads once you understand
-why the @func{switch_threads} that gets called is different from the
-@func{switch_threads} that returns.
+single-step from there.@footnote{@command{gdb} might tell you that
+@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
+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
+is to return from @func{switch_threads}. We realize this comment will
+seem cryptic to you at this point, but you will understand threads
+once you understand why the @func{switch_threads} that gets called is
+different from the @func{switch_threads} that returns.
@strong{Warning}: In Pintos, each thread is assigned a small,
fixed-size execution stack just under @w{4 kB} in size. The kernel
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
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
building block for real-time systems. Implement functions
@func{thread_set_priority} to set the priority of the running thread
and @func{thread_get_priority} to get the running thread's priority.
-(A thread can examine and modify only its own priority.) There are
-already prototypes for these functions in @file{threads/thread.h},
-which you should not change.
+(This API only allows a thread to examine and modify its own
+priority.) There are already prototypes for these functions in
+@file{threads/thread.h}, which you should not change.
Thread priority ranges from @code{PRI_MIN} (0) to @code{PRI_MAX} (59).
The initial thread priority is passed as an argument to
than the currently running thread, the current thread should
immediately yield the processor to the new thread. Similarly, when
threads are waiting for a lock, semaphore or condition variable, the
-highest priority waiting thread should be woken up first. A thread's
-priority may be set at any time, including while the thread is waiting
-on a lock, semaphore, or condition variable.
+highest priority waiting thread should be woken up first. A thread
+may set its priority at any time.
One issue with priority scheduling is ``priority inversion'': if a
high priority thread needs to wait for a low priority thread (for
You only need to implement priority donation when a thread is waiting
for a lock held by a lower-priority thread. You do not need to
-implement this fix for semaphores, condition variables or joins.
-However, you do need to implement priority scheduling in all cases.
+implement this fix for semaphores, condition variables, or joins,
+although you are welcome to do so. However, you do need to implement
+priority scheduling in all cases.
+
+You may assume a static priority for priority donation, that is, it is
+not necessary to ``re-donate'' a thread's priority if it changes
+(although you are free to do so).
@node Problem 1-4 Advanced Scheduler
@section Problem 1-4: Advanced Scheduler
at least one workload of your own design (i.e.@: in addition to the
provided test).
-You may assume a static priority for this problem. It is not necessary
-to ``re-donate'' a thread's priority if it changes (although you are
-free to do so).
-
You must write your code so that we can turn the MLFQS on and off at
compile time. By default, it must be off, but we must be able to turn
it on by inserting the line @code{#define MLFQS 1} in
Don't worry about the possibility of timer values overflowing. Timer
values are expressed as signed 63-bit numbers, which at 100 ticks per
second should be good for almost 2,924,712,087 years.
+
+@item
+@b{The test program mostly works but reports a few out-of-order
+wake ups. I think it's a problem in the test program. What gives?}
+@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:
+
+@itemize @bullet
+@item
+Make time slices longer by increasing @code{TIME_SLICE} in
+@file{timer.c} to a large value, such as 100.
+
+@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.
+
+@item
+@b{Should @file{p1-1.c} be expected to work with the MLFQS turned on?}
+
+No. The MLFQS will adjust priorities, changing thread ordering.
@end enumerate
@node Problem 1-2 Join FAQ
lock when H restores its priority.
@item
-@b{Why is pubtest3's FIFO test skipping some threads! I know my scheduler
-is round-robin'ing them like it's supposed to! Our output is like this:}
-
-@example
-Thread 0 goes.
-Thread 2 goes.
-Thread 3 goes.
-Thread 4 goes.
-Thread 0 goes.
-Thread 1 goes.
-Thread 2 goes.
-Thread 3 goes.
-Thread 4 goes.
-@end example
-
-@noindent @b{which repeats 5 times and then}
-
-@example
-Thread 1 goes.
-Thread 1 goes.
-Thread 1 goes.
-Thread 1 goes.
-Thread 1 goes.
-@end example
-
-This happens because context switches are being invoked by the test
-when it explicitly calls @func{thread_yield}. However, the time
-slice timer is still alive and so, every tick (by default), thread 1
-gets switched out (caused by @func{timer_interrupt} calling
-@func{intr_yield_on_return}) before it gets a chance to run its
-mainline. It is by coincidence that Thread 1 is the one that gets
-skipped in our example. If we use a different jitter value, the same
-behavior is seen where a thread gets started and switched out
-completely.
-
-Solution: Increase the value of @code{TIME_SLICE} in
-@file{devices/timer.c} to a very high value, such as 10000, to see
-that the threads will round-robin if they aren't interrupted.
+@b{Why is @file{p1-3.c}'s FIFO test skipping some threads? I know my
+scheduler is round-robin'ing them like it's supposed to. Our output
+starts out okay, but toward the end it starts getting out of order.}
+
+The usual problem is that the serial output buffer fills up. This is
+causing serial_putc() to block in thread @var{A}, so that thread
+@var{B} is scheduled. Thread @var{B} immediately tries to do output
+of its own and blocks on the serial lock (which is held by thread
+@var{A}). Now that we've wasted some time in scheduling and locking,
+typically some characters have been drained out of the serial buffer
+by the interrupt handler, so thread @var{A} can continue its output.
+After it finishes, though, some other thread (not @var{B}) is
+scheduled, because thread @var{B} was already scheduled while we
+waited for the buffer to drain.
+
+There's at least one other possibility. Context switches are being
+invoked by the test when it explicitly calls @func{thread_yield}.
+However, the time slice timer is still alive and so, every tick (by
+default), a thread gets switched out (caused by @func{timer_interrupt}
+calling @func{intr_yield_on_return}) before it gets a chance to run
+@func{printf}, effectively skipping it. If we use a different jitter
+value, the same behavior is seen where a thread gets started and
+switched out completely.
+
+Normally you can fix these problems using the same techniques
+suggested on problem 1-1 (@pxref{Out of Order 1-1}).
@item
@b{What happens when a thread is added to the ready list which has
its priority has been increased by a donation?}
The higher (donated) priority.
+
+@item
+@b{Should @file{p1-3.c} be expected to work with the MLFQS turned on?}
+
+No. The MLFQS will adjust priorities, changing thread ordering.
+
+@item
+@b{@func{printf} in @func{sema_up} or @func{sema_down} makes the
+system reboot!}
+
+Yes. These functions are called before @func{printf} is ready to go.
+You could add a global flag initialized to false and set it to true
+just before the first @func{printf} in @func{main}. Then modify
+@func{printf} itself to return immediately if the flag isn't set.
@end enumerate
@node Problem 1-4 Advanced Scheduler FAQ
projects / pintos-anon / blobdiff