Fix condition variable example.
[pintos-anon] / doc / threads.texi
index eb59d8a4267de1629c3f3d30037faab13c4d5a8b..dae47bb908a2fb87430c114e39efe15246e00c1f 100644 (file)
@@ -383,6 +383,33 @@ Problems 1-3 and 1-4 won't be needed for later projects.
 Problem 1-4 (MLFQS) builds on the features you implement in Problem
 1-3.  You should have Problem 1-3 fully working before you begin to
 tackle Problem 1-4.
+
+@item
+In the past, many groups divided the assignment into pieces, then each
+group member worked on his or her piece until just before the
+deadline, at which time the group reconvened to combine their code and
+submit.  @strong{This is a bad idea.  We do not recommend this
+approach.}  Groups that do this often find that two changes conflict
+with each other, requiring lots of last-minute debugging.  Some groups
+who have done this have turned in code that did not even successfully
+boot.
+
+Instead, we recommend integrating your team's changes early and often,
+using a source code control system such as CVS (@pxref{CVS}) or a
+group collaboration site such as SourceForge (@pxref{SourceForge}).
+This is less likely to produce surprises, because everyone can see
+everyone else's code as it is written, instead of just when it is
+finished.  These systems also make it possible to review changes and,
+when a change introduces a bug, drop back to working versions of code.
+
+@item
+You should expect to run into bugs that you simply don't understand
+while working on this and subsequent projects.  When you do, go back
+and reread the appendix on debugging tools, which is filled with
+useful debugging tips that should help you to get back up to speed
+(@pxref{Debugging Tools}).  Be sure to read the section on backtraces
+(@pxref{Backtraces}), which will help you to get the most out of every
+kernel panic or assertion failure.
 @end itemize
 
 @node Problem 1-1 Alarm Clock