Work on projects.

[pintos-anon] / doc / threads.texi

diff --git a/doc/threads.texi b/doc/threads.texi
index c1fb41d34929a831e4a464bef00f74cadbcb8dd5..4341cac9dcb4aa9213561d79e6dbbf6c2a565891 100644 (file)
--- a/doc/threads.texi
+++ b/doc/threads.texi
@@ -7,9 +7,9 @@ better understanding of synchronization problems. Additionally, you
 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::       
@@ -32,8 +32,10 @@ primitives (semaphores, locks, and condition variables).
 @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
@@ -52,8 +54,8 @@ synchronization primitives are used to force context switches when one
 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 
@@ -157,9 +159,9 @@ Problem 4.
 @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
@@ -173,9 +175,8 @@ advanced far enough.  This is undesirable because it wastes time that
 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
 @section Problem 1-2: Join
@@ -264,9 +265,9 @@ However, you do need to implement priority scheduling in all cases.
 @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
+explained in this @uref{mlfqs.pdf, , PDF} or @uref{mlfqs.ps, ,
+PostScript} file, to reduce the average response time for running jobs
+on your system.
 
 Demonstrate that your scheduling algorithm reduces response time
 relative to the original Pintos scheduling algorithm (round robin) for
@@ -357,17 +358,17 @@ attempt to sleep, you won't be able to call those in
 
 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.