-@node Project 1--Threads, Project 2--User Programs, Top, Top
+@node Project 1--Threads, Project 2--User Programs, Introduction, Top
@chapter Project 1: Threads
In this assignment, we give you a minimally functional thread system.
will use at least part of this increased functionality in future
assignments.
-You will be working in the @file{threads} and @file{devices}
-directories for this assignment. Compilation should be done in the
-@file{threads} directory.
+You will be working in primarily in the @file{threads} directory for
+this assignment, with some work in the @file{devices} directory on the
+side. Compilation should be done in the @file{threads} directory.
@menu
* Understanding Threads::
* Problem 1-3 Priority Scheduling::
* Problem 1-4 Advanced Scheduler::
* Threads FAQ::
+* Multilevel Feedback Scheduling::
@end menu
-@node Understanding Threads, Debugging versus Testing, Project 1--Threads, Project 1--Threads
+@node Understanding Threads
@section Understanding Threads
The first step is to read and understand the initial thread system.
@c FIXME: base system doesn't do anything. Debugger sucks.
However, there's a lot of magic going on in some of this code, so you
should compile and run the base system to see a simple test of the
-code. You should trace the execution using your favorite debugger to
-get a sense for what's going on.
+code. You should read through the source code by hand to see what's
+going on. If you like, you can add calls to @code{printf()} almost
+anywhere, then recompile and run to see what happens and in what
+order.
When a thread is created, you are creating a new context to be
scheduled. You provide a function to be run in this context as an
thread needs to wait for another thread to do something.
The exact mechanics of a context switch are pretty gruesome and have
-been provided for you in @file{switch.S} (this is 80@var{x}86
-assembly; don't worry about understanding it). It involves saving the
+been provided for you in @file{threads/switch.S} (this is 80@var{x}86
+assembly; don't worry about understanding it). It involves saving the
state of the currently running thread and restoring the state of the
thread we're switching to.
@c FIXME
limit. If you need larger chunks, consider using a linked structure
instead.
-@node Debugging versus Testing, Tips, Understanding Threads, Project 1--Threads
+@node Debugging versus Testing
@section Debugging versus Testing
When you're debugging code, it's useful to be able to be able to run a
as @var{seed} is varied. Thus, for the highest degree of confidence
you should test your code with many seed values.
-@node Tips, Problem 1-1 Alarm Clock, Debugging versus Testing, Project 1--Threads
+@node Tips
@section Tips
There should be no busy-waiting in any of your solutions to this
need to fix it for future assignments. The other parts can be turned
off in the future if you find you can't make them work quite right.
-Also keep in mind that Problem 4 (the MFQS) builds on the features you
+Also keep in mind that Problem 4 (the MLFQS) builds on the features you
implement in Problem 3, so to avoid unnecessary code duplication, it
would be a good idea to divide up the work among your team members
such that you have Problem 3 fully working before you begin to tackle
Problem 4.
-@node Problem 1-1 Alarm Clock, Problem 1-2 Join, Tips, Project 1--Threads
+@node Problem 1-1 Alarm Clock
@section Problem 1-2: Alarm Clock
Improve the implementation of the timer device defined in
-@file{devices/timer.c} by reimplementing @code{timer_msleep(0}.
-Threads call @code{timer_msleep(@var{x})} to suspend execution until
-time has advanced by at least @w{@var{x} milliseconds}. This is
+@file{devices/timer.c} by reimplementing @code{timer_sleep()}.
+Threads call @code{timer_sleep(@var{x})} to suspend execution until
+time has advanced by at least @w{@var{x} timer ticks}. This is
useful for threads that operate in real-time, for example, for
blinking the cursor once per second. There is no requirement that
threads start running immediately after waking up; just put them on
could potentially be used more profitably by another thread. Your
solution should not busy wait.
-The argument to @code{timer_msleep()} is expressed in milliseconds.
-You must convert it into timer ticks, rounding up. The code provided
-does this acceptably; there is no need to change it.
+The argument to @code{timer_sleep()} is expressed in timer ticks, not
+in milliseconds or some other unit.
-@node Problem 1-2 Join, Problem 1-3 Priority Scheduling, Problem 1-1 Alarm Clock, Project 1--Threads
+@node Problem 1-2 Join
@section Problem 1-2: Join
Implement @code{thread_join(struct thread *)} in
Be careful to program this function correctly. You will need its
functionality for project 2.
-@node Problem 1-3 Priority Scheduling, Problem 1-4 Advanced Scheduler, Problem 1-2 Join, Project 1--Threads
+@node Problem 1-3 Priority Scheduling
@section Problem 1-3 Priority Scheduling
Implement priority scheduling in Pintos. Priority
implement this fix for semaphores, condition variables or joins.
However, you do need to implement priority scheduling in all cases.
-@node Problem 1-4 Advanced Scheduler, Threads FAQ, Problem 1-3 Priority Scheduling, Project 1--Threads
+@node Problem 1-4 Advanced Scheduler
@section Problem 1-4 Advanced Scheduler
-Implement Solaris's multilevel feedback queue scheduler (MFQS), as
-explained below, to reduce the average response time for running jobs
-on your system.
-@c FIXME need link
+Implement Solaris's multilevel feedback queue scheduler (MLFQS) to
+reduce the average response time for running jobs on your system.
+@xref{Multilevel Feedback Scheduling}, for a detailed description of
+the MLFQS requirements.
Demonstrate that your scheduling algorithm reduces response time
relative to the original Pintos scheduling algorithm (round robin) for
to ``re-donate'' a thread's priority if it changes (although you are
free to do so).
-@node Threads FAQ, , Problem 1-4 Advanced Scheduler, Project 1--Threads
+@node Threads FAQ, Multilevel Feedback Scheduling, Problem 1-4 Advanced Scheduler, Project 1--Threads
@section FAQ
@enumerate 1
@enumerate 1
@item
@b{I am adding a new @file{.h} or @file{.c} file. How do I fix the
-@file{Makefile}s?}
+@file{Makefile}s?}@anchor{Adding c or h Files}
To add a @file{.c} file, edit the top-level @file{Makefile.build}.
You'll want to add your file to variable @samp{@var{dir}_SRC}, where
directory. Then run @code{make}. If your new file doesn't get
compiled, run @code{make clean} and then try again.
+When you modify the top-level @file{Makefile.build}, the modified
+version should be automatically copied to
+@file{threads/build/Makefile} when you re-run make. The opposite is
+not true, so any changes will be lost the next time you run @code{make
+clean} from the @file{threads} directory. Therefore, you should
+prefer to edit @file{Makefile.build} (unless your changes are meant to
+be truly temporary).
+
There is no need to edit the @file{Makefile}s to add a @file{.h} file.
@item
Having said that, you need to make sure that global data does not get
updated by multiple threads simultaneously executing
-@code{timer_msleep()}. Here are some pieces of information to think
+@code{timer_sleep()}. Here are some pieces of information to think
about:
@enumerate a
@item
Interrupts are turned off while @code{timer_interrupt()} runs. This
means that @code{timer_interrupt()} will not be interrupted by a
-thread running in @code{timer_msleep()}.
+thread running in @code{timer_sleep()}.
@item
-A thread in @code{timer_msleep()}, however, can be interrupted by a
+A thread in @code{timer_sleep()}, however, can be interrupted by a
call to @code{timer_interrupt()}, except when that thread has turned
off interrupts.
projects / pintos-anon / blobdiff