of the following sections: @ref{Introduction}, @ref{Coding Standards},
@ref{Project Documentation}, @ref{Debugging Tools}, and
@ref{Development Tools}. You should at least skim the material in
-@ref{Threads Tour}, but there's no need to fret over the details. To
-complete this project you will also need to read @ref{Multilevel
-Feedback Scheduling}.
+@ref{Threads Tour}. To complete this project you will also need to
+read @ref{Multilevel Feedback Scheduling}.
@menu
* Understanding Threads::
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
@item thread.c
@itemx thread.h
Basic thread support. Much of your work will take place in these
-files. @file{thread.h} defines @code{struct thread}, which you will
+files. @file{thread.h} defines @struct{thread}, which you will
modify in the first three projects.
@item switch.S
That is, a thread may only join its immediate children.
A thread need not ever be joined. Your solution should properly free
-all of a thread's resources, including its @code{struct thread},
+all of a thread's resources, including its @struct{thread},
whether it is ever joined or not, and regardless of whether the child
exits before or after its parent. That is, a thread should be freed
exactly once in all cases.