X-Git-Url: https://pintos-os.org/cgi-bin/gitweb.cgi?a=blobdiff_plain;f=doc%2Fthreads.texi;h=694c40e03b5c7ea51c494ae9f61d5295ef311c4c;hb=40983a542beab69a23f3e2b66f578615c51d2f50;hp=49183be9c6027536815b01b835a5bb700bb23083;hpb=2fb834e1f01b669851eee9e7a5598bc12df1e5ff;p=pintos-anon

diff --git a/doc/threads.texi b/doc/threads.texi
index 49183be..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.
 
@@ -495,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
@@ -656,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
@@ -673,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
@@ -684,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?}