-@item
-@b{What happens to the priority of the donating thread? Do the priorities
-get swapped?}
-
-No. Priority donation only changes the priority of the low-priority
-thread. The donating thread's priority stays unchanged. Also note
-that priorities aren't additive: if thread A (with priority 5) donates
-to thread B (with priority 3), then B's new priority is 5, not 8.
-
-@item
-@b{Can a thread's priority be changed while it is sitting on the ready
-queue?}
-
-Yes. Consider this case: low-priority thread L currently has a lock
-that high-priority thread H wants. H donates its priority to L (the
-lock holder). L finishes with the lock, and then loses the CPU and is
-moved to the ready queue. Now L's old priority is restored while it
-is in the ready queue.
-
-@item
-@b{Can a thread's priority change while it is sitting on the queue of a
-semaphore?}
-
-Yes. Same scenario as above except L gets blocked waiting on a new
-lock when H restores its priority.
-
-@item
-@b{Why is @file{p1-2.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
-higher priority than the currently running thread?}
-
-The correct behavior is to immediately yield the processor. Your
-solution must act this way.
-
-@item
-@b{What should @func{thread_get_priority} return in a thread while
-its priority has been increased by a donation?}
-
-The higher (donated) priority.
-
-@item
-@b{Should @file{p1-2.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