side. Compilation should be done in the @file{threads} directory.
Before you read the description of this project, you should read all
-of the following sections: @ref{Introduction}, @ref{Threads Tour},
-@ref{Coding Standards}, @ref{Project Documentation}, @ref{Debugging
-Tools}, and @ref{Development Tools}. To complete this project you
-will also need to read @ref{Multilevel Feedback Scheduling}.
+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}. 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.
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
projects / pintos-anon / blobdiff