X-Git-Url: https://pintos-os.org/cgi-bin/gitweb.cgi?a=blobdiff_plain;f=doc%2Fthreads.texi;h=694c40e03b5c7ea51c494ae9f61d5295ef311c4c;hb=139294a5bfab82f94deb1adc71a4db068ac864a3;hp=2e0032657560c8be1799fcb5b8906e1beb8ce077;hpb=2b285747143381620ebf4fb37df37d90fbf25705;p=pintos-anon

diff --git a/doc/threads.texi b/doc/threads.texi
index 2e00326..694c40e 100644
--- a/doc/threads.texi
+++ b/doc/threads.texi
@@ -77,10 +77,8 @@ 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
+the line number of the first declaration in @func{schedule}.}  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
@@ -339,7 +337,8 @@ assignment.  Furthermore, resist the temptation to directly disable
 interrupts in your solution by calling @func{intr_disable} or
 @func{intr_set_level}, although you may find doing so to be useful
 while debugging.  Instead, use semaphores, locks and condition
-variables to solve synchronization problems.  Hint: read the comments
+variables to solve synchronization problems.  Read the tour section on
+synchronization (@pxref{Synchronization}) or the comments
 in @file{threads/synch.h} if you're unsure what synchronization
 primitives may be used in what situations.
 
@@ -387,11 +386,17 @@ 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 @func{timer_sleep} is expressed in timer ticks, not
-in milliseconds or another unit.  There are @code{TIMER_FREQ} timer
+The argument to @func{timer_sleep} is expressed in timer ticks, not in
+milliseconds or any another unit.  There are @code{TIMER_FREQ} timer
 ticks per second, where @code{TIMER_FREQ} is a macro defined in
 @code{devices/timer.h}.
 
+Separate functions @func{timer_msleep}, @func{timer_usleep}, and
+@func{timer_nsleep} do exist for sleeping a specific number of
+milliseconds, microseconds, or nanoseconds, respectively, but these will
+call @func{timer_sleep} automatically when necessary.  You do not need
+to modify them.
+
 If your delays seem too short or too long, reread the explanation of the
 @option{-r} option to @command{pintos} (@pxref{Debugging versus
 Testing}).
@@ -489,7 +494,7 @@ A partial fix for this problem is to have the waiting thread
 the lock, then recall the donation once it has acquired the lock.
 Implement this fix.
 
-You will need to account for all different orders that priority
+You will need to account for all different orders in which priority
 donation and inversion can occur.  Be sure to handle multiple
 donations, in which multiple priorities are donated to a thread.  You
 must also handle nested donation: given high, medium, and low priority
@@ -650,7 +655,8 @@ off interrupts.
 @item
 Examples of synchronization mechanisms have been presented in lecture.
 Going over these examples should help you understand when each type is
-useful or needed.
+useful or needed.  @xref{Synchronization}, for specific information
+about synchronization in Pintos.
 @end enumerate
 
 @item
@@ -667,8 +673,8 @@ wake ups.  I think it's a problem in the test program.  What gives?}
 @anchor{Out of Order 1-1}
 
 This test is inherently full of race conditions.  On a real system it
-wouldn't work perfectly all the time either.  However, you can help it
-work more reliably:
+wouldn't work perfectly all the time either.  There are a few ways you
+can help it work more reliably:
 
 @itemize @bullet
 @item
@@ -678,17 +684,11 @@ Make time slices longer by increasing @code{TIME_SLICE} in
 @item
 Make the timer tick more slowly by decreasing @code{TIMER_FREQ} in
 @file{timer.h} to its minimum value of 19.
-
-@item
-Increase the serial output speed to the maximum of 115,200 bps by
-modifying the call to @func{set_serial} in @func{serial_init_poll} in
-@file{devices/serial.c}.
 @end itemize
 
 The former two changes are only desirable for testing problem 1-1 and
 possibly 1-3.  You should revert them before working on other parts
-of the project or turn in the project.  The latter is harmless, so you
-can retain it or revert it at your option.
+of the project or turn in the project.
 
 @item
 @b{Should @file{p1-1.c} be expected to work with the MLFQS turned on?}